info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
New Orician.. ;-)
86 views
Skip to first unread message
SD!
Apr 30, 2014, 7:57:20 PM4/30/14
to
Hi group,
I am an old CBM freak and - kind of - collector. Ran a CBM repair
workshop for some good years, back in the days. Some time ago a friend
of mine remembering what I was doing once for a living, said that he
took for me another "Commodore" from somewhere.. Sure he brought me the
machine in question, which was of course no "Commodore" but
"Commodoric-1" with a home-made label attached in front of "ORIC-1". As
I haven't had any of those in my hands before, I took it. The poor guy
was in a miserable shape. Not only /very/ dirty but also damaged /
non-working. I gave it a good bath first, disassembled the keyboard,
cleaned each key separately as well as the casing and then started to
look at whether he could be brought back to life and not only shape..
it happened to be relatively easy though: the 7905 and two RAM chips
were fried. After replacing those, the machine started nicely, saying
that it has 37631 bytes free (wow! that's even less than 38911 out of
64K that C-64 announces upon start :-)
And so I became acquainted with this nice, little fellow:
http://www.silverdr.com/tidbits/commodoric.jpg
which - as I learned on the way - happens to be quite a nifty, 6502
(everyone's favourite, huh?) based machine.
Now a few questions to more Oric experienced people out there:
1. there seems to be 64K on board but the label says 48K and the BASIC
says even less.. Looking at the schematic (I combined it into one sheet
here):
http://www.silverdr.com/tidbits/oric_schematic.gif
it seems like there is no mechanism to "turn off" the ROM
programmatically? The only thing that could do something about it is on
the external busport and called _ROMDIS. Is this the case? Is this
where the extra RAM is gone, for good? But why "only" 37631? In the
C-64 there are multiple ROMs and an extra RAM part that was not
available to BASIC but even with all those, it still had 38911
remaining for BASIC.. How is this here?
2. when I plug the machine in (power - kinda spectrum like... due to
lack of a switch) it sometimes shows vertical black and white strips
across the whole screen. They may go off by themselves or I need to
re-plug the computer before they disappear. Is this something "normal"
or should I look for more damages on the board?
3. The ROM (on an EPROM) shows:
BASIC V1.3
�1983 TANGERINE
�1992 FRANCES
which I bet is not the original ROM content. I read that the later
version called "ATMOS" had the ROM very much improved but it still
wouldn't be anything of 1992..
- what were the differences between ORIC-1 and ATMOS ROM contents?
- can a friendly sould dump me both original ones so that I could bring
that fellow closer to the original state and possibly check the newer
improvements?
Uff - so much for once. Greetings to fellow Oricians.
--
SD!
I am an old CBM freak and - kind of - collector. Ran a CBM repair
workshop for some good years, back in the days. Some time ago a friend
of mine remembering what I was doing once for a living, said that he
took for me another "Commodore" from somewhere.. Sure he brought me the
machine in question, which was of course no "Commodore" but
"Commodoric-1" with a home-made label attached in front of "ORIC-1". As
I haven't had any of those in my hands before, I took it. The poor guy
was in a miserable shape. Not only /very/ dirty but also damaged /
non-working. I gave it a good bath first, disassembled the keyboard,
cleaned each key separately as well as the casing and then started to
look at whether he could be brought back to life and not only shape..
it happened to be relatively easy though: the 7905 and two RAM chips
were fried. After replacing those, the machine started nicely, saying
that it has 37631 bytes free (wow! that's even less than 38911 out of
64K that C-64 announces upon start :-)
And so I became acquainted with this nice, little fellow:
http://www.silverdr.com/tidbits/commodoric.jpg
which - as I learned on the way - happens to be quite a nifty, 6502
(everyone's favourite, huh?) based machine.
Now a few questions to more Oric experienced people out there:
1. there seems to be 64K on board but the label says 48K and the BASIC
says even less.. Looking at the schematic (I combined it into one sheet
here):
http://www.silverdr.com/tidbits/oric_schematic.gif
it seems like there is no mechanism to "turn off" the ROM
programmatically? The only thing that could do something about it is on
the external busport and called _ROMDIS. Is this the case? Is this
where the extra RAM is gone, for good? But why "only" 37631? In the
C-64 there are multiple ROMs and an extra RAM part that was not
available to BASIC but even with all those, it still had 38911
remaining for BASIC.. How is this here?
2. when I plug the machine in (power - kinda spectrum like... due to
lack of a switch) it sometimes shows vertical black and white strips
across the whole screen. They may go off by themselves or I need to
re-plug the computer before they disappear. Is this something "normal"
or should I look for more damages on the board?
3. The ROM (on an EPROM) shows:
BASIC V1.3
�1983 TANGERINE
�1992 FRANCES
which I bet is not the original ROM content. I read that the later
version called "ATMOS" had the ROM very much improved but it still
wouldn't be anything of 1992..
- what were the differences between ORIC-1 and ATMOS ROM contents?
- can a friendly sould dump me both original ones so that I could bring
that fellow closer to the original state and possibly check the newer
improvements?
Uff - so much for once. Greetings to fellow Oricians.
--
SD!
Simon
May 1, 2014, 8:29:28 AM5/1/14
to
Hi there,
> 1. there seems to be 64K on board but the label says 48K and the BASIC
> says even less.. Looking at the schematic (I combined it into one sheet
> here):
>
> http://www.silverdr.com/tidbits/oric_schematic.gif
>
> it seems like there is no mechanism to "turn off" the ROM
> programmatically? The only thing that could do something about it is on
> the external busport and called _ROMDIS. Is this the case?
As I'm a total ignorant of electronics, I can't say 100% your
explanation is the right one, but I'd say so. Facts from user point of
view are: no one can access the 16K of RAM that is masked by the ROM,
unless an external device manages it (disk drives do and allow swapping
with overlay RAM).
> Is this where
> the extra RAM is gone, for good? But why "only" 37631?
Yes. There's even less displayed because it is calculated by removing
the memory used by the system - including the room used by the high
resolution graphic screen (8K). If you don't want to use high resolution
graphics, you can get this part of RAM back with the command GRAB.
Then PRINT FRE(0) should display you the new amount of available memory.
> 2. when I plug the machine in (power - kinda spectrum like... due to
> lack of a switch) it sometimes shows vertical black and white strips
> across the whole screen. They may go off by themselves or I need to
> re-plug the computer before they disappear. Is this something "normal"
> or should I look for more damages on the board?
This happens to me quite a lot, not sure why... I let hardware experts
tell if this is really "normal" and harmless for the computer.
> 3. The ROM (on an EPROM) shows:
>
> BASIC V1.3
> �1983 TANGERINE
> �1992 FRANCES
Very interesting. This could be a ROM designed by the author of
Euphoric, the 1st Oric emulator on PC.
Hope you can dump it :)
> - what were the differences between ORIC-1 and ATMOS ROM contents?
> - can a friendly sould dump me both original ones so that I could bring
> that fellow closer to the original state and possibly check the newer
> improvements?
You should find them at http://oric.free.fr/ROMS/
Differences between ROM 1.0 (Oric-1) and 1.1 (Atmos) were mainly bug
corrections or code optimization here or there. There actually even
exist several 1.1 official versions, correcting new bugs!
Hope that helps
Simon
> 1. there seems to be 64K on board but the label says 48K and the BASIC
> says even less.. Looking at the schematic (I combined it into one sheet
> here):
>
> http://www.silverdr.com/tidbits/oric_schematic.gif
>
> it seems like there is no mechanism to "turn off" the ROM
> programmatically? The only thing that could do something about it is on
> the external busport and called _ROMDIS. Is this the case?
explanation is the right one, but I'd say so. Facts from user point of
view are: no one can access the 16K of RAM that is masked by the ROM,
unless an external device manages it (disk drives do and allow swapping
with overlay RAM).
> Is this where
> the extra RAM is gone, for good? But why "only" 37631?
the memory used by the system - including the room used by the high
resolution graphic screen (8K). If you don't want to use high resolution
graphics, you can get this part of RAM back with the command GRAB.
Then PRINT FRE(0) should display you the new amount of available memory.
> 2. when I plug the machine in (power - kinda spectrum like... due to
> lack of a switch) it sometimes shows vertical black and white strips
> across the whole screen. They may go off by themselves or I need to
> re-plug the computer before they disappear. Is this something "normal"
> or should I look for more damages on the board?
tell if this is really "normal" and harmless for the computer.
> 3. The ROM (on an EPROM) shows:
>
> BASIC V1.3
> �1983 TANGERINE
> �1992 FRANCES
Euphoric, the 1st Oric emulator on PC.
Hope you can dump it :)
> - what were the differences between ORIC-1 and ATMOS ROM contents?
> - can a friendly sould dump me both original ones so that I could bring
> that fellow closer to the original state and possibly check the newer
> improvements?
Differences between ROM 1.0 (Oric-1) and 1.1 (Atmos) were mainly bug
corrections or code optimization here or there. There actually even
exist several 1.1 official versions, correcting new bugs!
Hope that helps
Simon
Andre Majorel
May 1, 2014, 8:38:17 AM5/1/14
to
On 2014-04-30, SD! <em...@domain.com> wrote:
> 1. there seems to be 64K on board but the label says 48K and
> the BASIC says even less.. Looking at the schematic (I
> combined it into one sheet here):
>
> http://www.silverdr.com/tidbits/oric_schematic.gif
>
> it seems like there is no mechanism to "turn off" the ROM
> programmatically? The only thing that could do something about
> it is on the external busport and called _ROMDIS. Is this the
> case? Is this where the extra RAM is gone, for good? But why
> "only" 37631? In the C-64 there are multiple ROMs and an extra
> RAM part that was not available to BASIC but even with all
> those, it still had 38911 remaining for BASIC.. How is this
> here?
IC7 (proprietary ULA HCS10017) is responsible for memory
> 1. there seems to be 64K on board but the label says 48K and
> the BASIC says even less.. Looking at the schematic (I
> combined it into one sheet here):
>
> http://www.silverdr.com/tidbits/oric_schematic.gif
>
> it seems like there is no mechanism to "turn off" the ROM
> programmatically? The only thing that could do something about
> it is on the external busport and called _ROMDIS. Is this the
> case? Is this where the extra RAM is gone, for good? But why
> "only" 37631? In the C-64 there are multiple ROMs and an extra
> RAM part that was not available to BASIC but even with all
> those, it still had 38911 remaining for BASIC.. How is this
> here?
mapping :
0x0300-0x03ff VIA 6522
0xc000-0xffff BASIC ROM
the rest RAM
To access the top 16 kB of the RAM, you need to "unmap" the ROM,
which involves manipulating !MAP, !ROMDIS and maybe others at
precise times in the 1 MHz cycle. There is no circuitry to do
that inside the Oric. You can look at floppy disc controllers to
see what it took (they used the top 16 kB of the RAM to store
the DOS). The Jasmin used a PAL but the Microdisc and Cumana did
it with SSI/MSI 74LS chips.
> 2. when I plug the machine in (power - kinda spectrum like... due to
> lack of a switch) it sometimes shows vertical black and white strips
> across the whole screen. They may go off by themselves or I need to
> re-plug the computer before they disappear. Is this something "normal"
> or should I look for more damages on the board?
RAM (about 3 seconds).
> 3. The ROM (on an EPROM) shows:
>
> BASIC V1.3
> �1983 TANGERINE
> �1992 FRANCES
>
> which I bet is not the original ROM content. I read that the later
> version called "ATMOS" had the ROM very much improved but it still
> wouldn't be anything of 1992..
>
> - what were the differences between ORIC-1 and ATMOS ROM contents?
enclosure and keyboard but otherwise almost identical.
Differences between the ROMs were bug fixes, a few new
instructions and... new addresses for most routines and system
variables. <g>
> - can a friendly sould dump me both original ones so that I
> could bring that fellow closer to the original state and
> possibly check the newer improvements?
contains dumps of ROMs 1.0 and 1.1. But V1.3 is probably better
for practical purposes.
--
Andr� Majorel http://www.teaser.fr/~amajorel/
Endless variations make it all seem new
Can you recognise the patterns that you find ?
SD!
May 7, 2014, 9:29:28 AM5/7/14
to
On 2014-05-01 12:29:28 +0000, Simon said:
> Hi there,
>
>> 1. there seems to be 64K on board but the label says 48K and the BASIC
>> says even less.. Looking at the schematic (I combined it into one sheet
>> here):
>>
>> http://www.silverdr.com/tidbits/oric_schematic.gif
>>
>> it seems like there is no mechanism to "turn off" the ROM
>> programmatically? The only thing that could do something about it is on
>> the external busport and called _ROMDIS. Is this the case?
>
> As I'm a total ignorant of electronics, I can't say 100% your
> explanation is the right one, but I'd say so. Facts from user point of
> view are: no one can access the 16K of RAM that is masked by the ROM,
> unless an external device manages it (disk drives do and allow swapping
> with overlay RAM).
>
>> Is this where the extra RAM is gone, for good? But why "only" 37631?
>
> Yes. There's even less displayed because it is calculated by removing
> the memory used by the system - including the room used by the high
> resolution graphic screen (8K). If you don't want to use high
> resolution graphics, you can get this part of RAM back with the command
> GRAB.
> Then PRINT FRE(0) should display you the new amount of available memory.
Ah, so it is not only that the 16K masked by ROM falls off, another 8K
> Hi there,
>
>> 1. there seems to be 64K on board but the label says 48K and the BASIC
>> says even less.. Looking at the schematic (I combined it into one sheet
>> here):
>>
>> http://www.silverdr.com/tidbits/oric_schematic.gif
>>
>> it seems like there is no mechanism to "turn off" the ROM
>> programmatically? The only thing that could do something about it is on
>> the external busport and called _ROMDIS. Is this the case?
>
> As I'm a total ignorant of electronics, I can't say 100% your
> explanation is the right one, but I'd say so. Facts from user point of
> view are: no one can access the 16K of RAM that is masked by the ROM,
> unless an external device manages it (disk drives do and allow swapping
> with overlay RAM).
>
>> Is this where the extra RAM is gone, for good? But why "only" 37631?
>
> Yes. There's even less displayed because it is calculated by removing
> the memory used by the system - including the room used by the high
> resolution graphic screen (8K). If you don't want to use high
> resolution graphics, you can get this part of RAM back with the command
> GRAB.
> Then PRINT FRE(0) should display you the new amount of available memory.
for the frame buffer and this is already 24K, which leaves only 40
left. Deduct zeropage, some buffers, screen, etc. and that's where it
ends (somewhere short of 37K), right? Interesting that one has to
opt-out rather than opt-in reserving RAM for the hi-res frame buffer..
>> 2. when I plug the machine in (power - kinda spectrum like... due to
>> lack of a switch) it sometimes shows vertical black and white strips
>> across the whole screen. They may go off by themselves or I need to
>> re-plug the computer before they disappear. Is this something "normal"
>> or should I look for more damages on the board?
>
> This happens to me quite a lot, not sure why... I let hardware experts
> tell if this is really "normal" and harmless for the computer.
failure.
>> 3. The ROM (on an EPROM) shows:
>>
>> BASIC V1.3
>> �1983 TANGERINE
>> �1992 FRANCES
>
> Very interesting. This could be a ROM designed by the author of
> Euphoric, the 1st Oric emulator on PC. Hope you can dump it :)
http://www.silverdr.com/tidbits/basic_v1.3_frances_nonoriginal.bin
if anyone's interested.
>> - what were the differences between ORIC-1 and ATMOS ROM contents?
>> - can a friendly sould dump me both original ones so that I could bring
>> that fellow closer to the original state and possibly check the newer
>> improvements?
>
> You should find them at http://oric.free.fr/ROMS/
> Differences between ROM 1.0 (Oric-1) and 1.1 (Atmos) were mainly bug
> corrections or code optimization here or there. There actually even
> exist several 1.1 official versions, correcting new bugs!
Should arrive soon. I shall check what ROM is there in.
> Hope that helps
> Simon
Thanks, Simon. Every little bit helps.
--
SD!
SD!
May 7, 2014, 11:35:05 AM5/7/14
to
On 2014-05-01 12:38:17 +0000, Andre Majorel said:
> IC7 (proprietary ULA HCS10017) is responsible for memory
> mapping :
> 0x0300-0x03ff VIA 6522
> 0xc000-0xffff BASIC ROM
> the rest RAM
>
> To access the top 16 kB of the RAM, you need to "unmap" the ROM,
> which involves manipulating !MAP, !ROMDIS and maybe others at
> precise times in the 1 MHz cycle. There is no circuitry to do
> that inside the Oric.
> You can look at floppy disc controllers to
> see what it took (they used the top 16 kB of the RAM to store
> the DOS). The Jasmin used a PAL but the Microdisc and Cumana did
> it with SSI/MSI 74LS chips.
Actually my first cursory glance at the schematic was wrong. I noticed
> IC7 (proprietary ULA HCS10017) is responsible for memory
> mapping :
> 0x0300-0x03ff VIA 6522
> 0xc000-0xffff BASIC ROM
> the rest RAM
>
> To access the top 16 kB of the RAM, you need to "unmap" the ROM,
> which involves manipulating !MAP, !ROMDIS and maybe others at
> precise times in the 1 MHz cycle. There is no circuitry to do
> that inside the Oric.
> You can look at floppy disc controllers to
> see what it took (they used the top 16 kB of the RAM to store
> the DOS). The Jasmin used a PAL but the Microdisc and Cumana did
> it with SSI/MSI 74LS chips.
there is the "LK3", which is probably a solder-jumper (didn't check at
the board - machine is re-assembled now) and the same line (coming from
ULA) goes to the optional NAND gates set, meaning ULA could
theoretically "unmap" the ROM all by itself but I understand that it
has the memory mapping equations fixed, right? There is no register bit
that could affect when this line gets its active-low state. It's
unconditionally activated by the address-bus values, right?
>> 2. when I plug the machine in (power - kinda spectrum like... due to
>> lack of a switch) it sometimes shows vertical black and white strips
>> across the whole screen. They may go off by themselves or I need to
>> re-plug the computer before they disappear. Is this something "normal"
>> or should I look for more damages on the board?
>
> It's normal. They go away after the ROM is done initialising the
> RAM (about 3 seconds).
wait long enough. Although I believe I waited more than 3s.. Shall
check again in a free moment.
>> 3. The ROM (on an EPROM) shows:
>>
>> BASIC V1.3
>> �1983 TANGERINE
>> �1992 FRANCES
>>
>> which I bet is not the original ROM content. I read that the later
>> version called "ATMOS" had the ROM very much improved but it still
>> wouldn't be anything of 1992..
>>
>> - what were the differences between ORIC-1 and ATMOS ROM contents?
>
> The Oric-1 had ROM V1.0. The Atmos had ROM V1.1 and a new
> enclosure and keyboard but otherwise almost identical.
> Differences between the ROMs were bug fixes, a few new
> instructions and... new addresses for most routines and system
> variables. <g>
>
>> - can a friendly sould dump me both original ones so that I
>> could bring that fellow closer to the original state and
>> possibly check the newer improvements?
>
> http://www.teaser.fr/~amajorel/xeuphoric/xeuphoric-0.19.0.tar.gz
> contains dumps of ROMs 1.0 and 1.1. But V1.3 is probably better
> for practical purposes.
the original (1.1)?
--
SD!
Andre Majorel
May 8, 2014, 3:56:03 AM5/8/14
to
On 2014-05-07, SD! <em...@domain.com> wrote:
> Actually my first cursory glance at the schematic was wrong. I
> noticed there is the "LK3", which is probably a solder-jumper
> (didn't check at the board - machine is re-assembled now)
Most Orics were shipped with one 16 kB ROM but the PCB has
> Actually my first cursory glance at the schematic was wrong. I
> noticed there is the "LK3", which is probably a solder-jumper
> (didn't check at the board - machine is re-assembled now)
provision for a pair of 8 kB ROM chips (by adding IC11 and
leaving LK3 open).
> and the same line (coming from ULA) goes to the optional NAND
> gates set, meaning ULA could theoretically "unmap" the ROM all
> by itself but I understand that it has the memory mapping
> equations fixed, right? There is no register bit that could
> affect when this line gets its active-low state. It's
> unconditionally activated by the address-bus values, right?
is hard-wired. The mapping can be disabled but not by software,
only by hardware.
This might seem strange to someone used to the Commodore 64 but
the ULA doesn't have any registers. If you think that sucks,
wait until you've looked into the video system...
It's worth keeping in mind that the Oric was a cheap machine,
much like its direct competitor the Spectrum. When the Oric-1
came out, it cost about half the price of a C64. The designers
cut quite a few corners.
> It's just that sometimes they don't want to go away. Maybe I
> didn't wait long enough. Although I believe I waited more than
> 3s.. Shall check again in a free moment.
It happens to me too from time to time. If I don't get a prompt
after 3 or 4 seconds, I just remove the power plug, wait a
second and put it back on.
>> But V1.3 is probably better for practical purposes.
>
> Should I understand that you know this "V1.3" and what it
> changed from the original (1.1)?
compatibility, meaning keeping all BASIC instructions and
changing as few addresses as possible in the ROM. So it's
unlikely to be radically different from V1.1.
Simon
May 8, 2014, 4:04:04 AM5/8/14
to
Andre Majorel a �crit :
with ROMs to do transfers thru the parallel port (to the Atari ST).
A glance at the file you've dumped shows the STORE and RECALL commands
have been replaced by SEND and RECIEVE. Si it's more a specialized ROM
than a general improvement.
>>> But V1.3 is probably better for practical purposes.
>> Should I understand that you know this "V1.3" and what it
>> changed from the original (1.1)?
>
> I don't. I'm just assuming that the author would want backwards
> compatibility, meaning keeping all BASIC instructions and
> changing as few addresses as possible in the ROM. So it's
> unlikely to be radically different from V1.1.
I've asked the author and he told me around 1992 he was playing a lot
>> Should I understand that you know this "V1.3" and what it
>> changed from the original (1.1)?
>
> I don't. I'm just assuming that the author would want backwards
> compatibility, meaning keeping all BASIC instructions and
> changing as few addresses as possible in the ROM. So it's
> unlikely to be radically different from V1.1.
with ROMs to do transfers thru the parallel port (to the Atari ST).
A glance at the file you've dumped shows the STORE and RECALL commands
have been replaced by SEND and RECIEVE. Si it's more a specialized ROM
than a general improvement.
Andre Majorel
May 8, 2014, 2:54:01 PM5/8/14
to
On 2014-05-08, Simon <n...@no.no> wrote:
>> I don't. I'm just assuming that the author would want backwards
>> compatibility, meaning keeping all BASIC instructions and
>> changing as few addresses as possible in the ROM. So it's
>> unlikely to be radically different from V1.1.
>
> I've asked the author and he told me around 1992 he was playing a lot
> with ROMs to do transfers thru the parallel port (to the Atari ST).
> A glance at the file you've dumped shows the STORE and RECALL commands
> have been replaced by SEND and RECEIVE. Si it's more a specialized ROM
>> I don't. I'm just assuming that the author would want backwards
>> compatibility, meaning keeping all BASIC instructions and
>> changing as few addresses as possible in the ROM. So it's
>> unlikely to be radically different from V1.1.
>
> I've asked the author and he told me around 1992 he was playing a lot
> with ROMs to do transfers thru the parallel port (to the Atari ST).
> A glance at the file you've dumped shows the STORE and RECALL commands
> than a general improvement.
So much for that particular assumption, then ! Thanks for
setting the record straight. For the archives,
http://www.silverdr.com/tidbits/basic_v1.3_frances_nonoriginal.bin
MD5 3b9b9dc940366dc13d2cc2e5e8495172
SHA-1 3469ba23723ce68feab21f644b8f6344be0e029e
SHA-256 5967c262633804b9ad9cf725d2a7f9c848a256ba2c39fe635aa71d3d889bd85c
BASIC V1.3
�1983 TANGERINE
�1992 FRANCES
37631 BYTES FREE
�1983 TANGERINE
�1992 FRANCES
Andre Majorel
May 10, 2014, 5:56:19 AM5/10/14
to
>> Yes. There's even less displayed because it is calculated by
>> removing the memory used by the system - including the room
>> used by the high resolution graphic screen (8K). If you don't
>> want to use high resolution graphics, you can get this part
>> of RAM back with the command GRAB.
>> Then PRINT FRE(0) should display you the new amount of
>> available memory.
>
> Ah, so it is not only that the 16K masked by ROM falls off,
> another 8K for the frame buffer and this is already 24K, which
> leaves only 40 left. Deduct zeropage, some buffers, screen,
> etc. and that's where it ends (somewhere short of 37K), right?
Right.
>> removing the memory used by the system - including the room
>> used by the high resolution graphic screen (8K). If you don't
>> want to use high resolution graphics, you can get this part
>> of RAM back with the command GRAB.
>> Then PRINT FRE(0) should display you the new amount of
>> available memory.
>
> Ah, so it is not only that the 16K masked by ROM falls off,
> another 8K for the frame buffer and this is already 24K, which
> leaves only 40 left. Deduct zeropage, some buffers, screen,
> etc. and that's where it ends (somewhere short of 37K), right?
> Interesting that one has to opt-out rather than opt-in
> reserving RAM for the hi-res frame buffer..
is more than what most Oric software used. (Loading time :
around 5 minutes.)
If you make GRAB the default, you create a step near the
beginning of the learning curve ("I can't figure out how to use
HIRES, all it does is print "?DISP TYPE MISMATCH ERROR").
I reckon that the pragmatic "human factors" advantages of making
RELEASE the default outweigh the better conceptual neatness of
the alternative.
Was it the other way around on the C64 ?
SD!
May 20, 2014, 7:48:48 PM5/20/14
to
On 2014-05-10 09:56:19 +0000, Andre Majorel said:
>> Interesting that one has to opt-out rather than opt-in
>> reserving RAM for the hi-res frame buffer..
>
> If you make RELEASE the default, you're limited to 37 kB, which
> is more than what most Oric software used. (Loading time :
> around 5 minutes.)
Not too bad anyway. There are 8-bit systems that would scream out of
>> Interesting that one has to opt-out rather than opt-in
>> reserving RAM for the hi-res frame buffer..
>
> If you make RELEASE the default, you're limited to 37 kB, which
> is more than what most Oric software used. (Loading time :
> around 5 minutes.)
ecstasy if they could load 37KiB from tape in five minutes!
> If you make GRAB the default, you create a step near the
> beginning of the learning curve ("I can't figure out how to use
> HIRES, all it does is print "?DISP TYPE MISMATCH ERROR").
>
> I reckon that the pragmatic "human factors" advantages of making
> RELEASE the default outweigh the better conceptual neatness of
> the alternative.
actually "feel" those advantages :-) but this is some kind of possible
explanation. If the designers felt like wasting 16KiB of precious RAM
beneath ROM, the extra 8KiB given away by default to the HIRES buffer
doesn't seem like much of a deal. Especially when a way to recover it
when needed is there.
> Was it the other way around on the C64 ?
output without a steep learning curve on the hardware, memory,
locations, registers and God knows what else. Definitely no HIRES
graphics from within BASIC without multiple POKEs of some cryptic (to
an untrained eye) numbers. And moreover no automatic memory
handling/reserving. One could easily cause program and graphics overlap
in the same mem range, with obvious, catastrophic results..
As hard and sucky as it may seem - in the end it caused a whole
generation of programmers to dig out the knowledge and actually
understand how the machine (and all computers by extension) works.
Seems that less was more in this particular case. Not that I'd
recommend this approach everywhere though ;-)
--
SD!
SD!
May 20, 2014, 8:14:47 PM5/20/14
to
On 2014-05-08 07:56:03 +0000, Andre Majorel said:
>> Actually my first cursory glance at the schematic was wrong. I
>> noticed there is the "LK3", which is probably a solder-jumper
>> (didn't check at the board - machine is re-assembled now)
>
> Most Orics were shipped with one 16 kB ROM but the PCB has
> provision for a pair of 8 kB ROM chips (by adding IC11 and
> leaving LK3 open).
Right, I noticed that.
>> Actually my first cursory glance at the schematic was wrong. I
>> noticed there is the "LK3", which is probably a solder-jumper
>> (didn't check at the board - machine is re-assembled now)
>
> Most Orics were shipped with one 16 kB ROM but the PCB has
> provision for a pair of 8 kB ROM chips (by adding IC11 and
> leaving LK3 open).
>> and the same line (coming from ULA) goes to the optional NAND
>> gates set, meaning ULA could theoretically "unmap" the ROM all
>> by itself but I understand that it has the memory mapping
>> equations fixed, right? There is no register bit that could
>> affect when this line gets its active-low state. It's
>> unconditionally activated by the address-bus values, right?
>
> You got the idea. The address range in which the ROM is mapped
> is hard-wired. The mapping can be disabled but not by software,
> only by hardware.
which goes to pin 27 of the ROM chip. While this is somewhat ok when
there is a 23128 mask programmable ROM, I am not sure it will work so
well with all EPROMs. OK - unless we have some of original ORIC
designers hanging around here, I probably won't get any authoritative
answer as to why this is done so. I am still surprised that they gave
away 16KiB so easily in the times when this amount of RAM was quite a
big deal. And they even didn't call the machine "64K" but rather "48K"
when they easily could get some marketing edge..
> This might seem strange to someone used to the Commodore 64 but
> the ULA doesn't have any registers. If you think that sucks,
> wait until you've looked into the video system...
do about the way things are displayed? No registers - no manipulations?
I see it is the ULA that generates all RGB and SYNC. But without any
registers in the address space that means again a "hardwired"
framebuffer with nothing else than slow memory operations on it? But
there was this notion about GRAB/RELEASE, which is supposed to change
between HIRES and - well - NON-HIRES I presume, so how does this work
without any registers in the ULA?
> It's worth keeping in mind that the Oric was a cheap machine,
> much like its direct competitor the Spectrum. When the Oric-1
> came out, it cost about half the price of a C64. The designers
> cut quite a few corners.
even more "ULA" than the Spectrum one I tend to believe ;-)
>> It's just that sometimes they don't want to go away. Maybe I
>> didn't wait long enough. Although I believe I waited more than
>> 3s.. Shall check again in a free moment.
>
> Sorry, I wasn't reading closely enough. Don't worry about that.
> It happens to me too from time to time. If I don't get a prompt
> after 3 or 4 seconds, I just remove the power plug, wait a
> second and put it back on.
power-cycle too. But that means that there is something fishy. In the
POST timings probably. Another corner cut somewhere, probably..
--
SD!
SD!
May 20, 2014, 8:16:11 PM5/20/14
to
much faster than tape LOAD for example.
--
SD!
SD!
May 20, 2014, 8:18:42 PM5/20/14
to
On 2014-05-08 18:54:01 +0000, Andre Majorel said:
> On 2014-05-08, Simon <n...@no.no> wrote:
>
>>> I don't. I'm just assuming that the author would want backwards
>>> compatibility, meaning keeping all BASIC instructions and
>>> changing as few addresses as possible in the ROM. So it's
>>> unlikely to be radically different from V1.1.
>>
>> I've asked the author and he told me around 1992 he was playing a lot
>> with ROMs to do transfers thru the parallel port (to the Atari ST).
>> A glance at the file you've dumped shows the STORE and RECALL commands
>> have been replaced by SEND and RECEIVE. Si it's more a specialized ROM
>> than a general improvement.
>
> So much for that particular assumption, then ! Thanks for
> setting the record straight. For the archives,
>
> http://www.silverdr.com/tidbits/basic_v1.3_frances_nonoriginal.bin
> MD5 3b9b9dc940366dc13d2cc2e5e8495172
> SHA-1 3469ba23723ce68feab21f644b8f6344be0e029e
> SHA-256 5967c262633804b9ad9cf725d2a7f9c848a256ba2c39fe635aa71d3d889bd85c
> BASIC V1.3
> �1983 TANGERINE
> �1992 FRANCES
> 37631 BYTES FREE
If there is a more appropriate place to store this dump for the future
> On 2014-05-08, Simon <n...@no.no> wrote:
>
>>> I don't. I'm just assuming that the author would want backwards
>>> compatibility, meaning keeping all BASIC instructions and
>>> changing as few addresses as possible in the ROM. So it's
>>> unlikely to be radically different from V1.1.
>>
>> I've asked the author and he told me around 1992 he was playing a lot
>> with ROMs to do transfers thru the parallel port (to the Atari ST).
>> A glance at the file you've dumped shows the STORE and RECALL commands
>> have been replaced by SEND and RECEIVE. Si it's more a specialized ROM
>> than a general improvement.
>
> So much for that particular assumption, then ! Thanks for
> setting the record straight. For the archives,
>
> http://www.silverdr.com/tidbits/basic_v1.3_frances_nonoriginal.bin
> MD5 3b9b9dc940366dc13d2cc2e5e8495172
> SHA-1 3469ba23723ce68feab21f644b8f6344be0e029e
> SHA-256 5967c262633804b9ad9cf725d2a7f9c848a256ba2c39fe635aa71d3d889bd85c
> BASIC V1.3
> �1983 TANGERINE
> �1992 FRANCES
> 37631 BYTES FREE
generation, I think it is better to move it there. My "tidbits" may go
away at some point without notice ;-)
--
SD!
Brian Gregory
Apr 10, 2016, 7:43:22 PM4/10/16
to
On 01/05/2014 00:57, SD! wrote:
> 2. when I plug the machine in (power - kinda spectrum like... due to
> lack of a switch) it sometimes shows vertical black and white strips
> across the whole screen. They may go off by themselves or I need to
> re-plug the computer before they disappear. Is this something "normal"
> or should I look for more damages on the board?
The strips should go away after self test.
> 2. when I plug the machine in (power - kinda spectrum like... due to
> lack of a switch) it sometimes shows vertical black and white strips
> across the whole screen. They may go off by themselves or I need to
> re-plug the computer before they disappear. Is this something "normal"
> or should I look for more damages on the board?
If they don't you will probably find it starts up better if you apply AC
power to the power adapter before you connect it to the computer.
You could try changing C21 from 1μF to a higher (maybe 47μF) value as a
possible way to make it start up more reliably.
But basically the problem with it, as it is, is that it needs the
internal 5V to go very quickly from 0V to 5V at power on or it doesn't
start up reliably.
--
Brian Gregory (in the UK).
To email me please remove all the letter vee from my email address.
0 new messages