3D Fongus with Erebus : does not load
Re: 3D Fongus with Erebus : does not load
Does your two Oric show the same patterns on screen when booted? If not, it could simply be that The Ultra does not properly initialize some variables which by default are cleared on some versions of the Oric but not on other.
Re: 3D Fongus with Erebus : does not load
Dbug is right. The Oric ROM initializes normal RAM, but not page 0. I am not sure if due to different models of RAM chips or what, some Orics seem to start with different values in page 0.
- mikeb
- Flight Lieutenant
- Posts: 282
- Joined: Wed Sep 05, 2018 8:03 pm
- Location: West Midlands, UK
- Contact:
Re: 3D Fongus with Erebus : does not load
Interesting point you raise on incomplete RAM testing -- I just went to check my Adv. User Guide ROM disassembly -- you're right.
Worse: It's not just page 0 that is untested.
It appears a 16bit pointer at #0C/#0D is used to probe the "current" location, and is set to #OC=#FF (1.1 ROM at #FA22) and #0D=#03 (at #FA3A).
The next instruction is inside the test loop, which increments the pointer. So RAM is only tested from #0400 upward to end of memory (set by pointer in #0E,#0F) which terminates at #C000 or #4000 (for 48k or 16k computer).
This means the first 4 pages of memory go untested, as does "shadow" memory.
Unless you do a non-destructive memory test, it's hard to test page 0 when you're already using it for pointers. Same applies for page 1 (stack) which is already in use by this point. Page 3 is a mystery, as all sorts of hardware overlays that (at very least, the VIA chip), so testing that is impossible, as is the shadow RAM, inaccessible to a lone Oric with no hardware assistance.
Tested memory is always left with 0x55 ("U"), but the value in un-initialized memory is not reliable, because although if the DRAM chips are assumed to be all discharged, that doesn't guarantee all 0's or all 1's -- simply because the internal construction of a DRAM chip almost always involves some bits being stored as true logic, others as inverted logic. This is at the whim of the designer of the chip.
Always initialize your variables
Worse: It's not just page 0 that is untested.
It appears a 16bit pointer at #0C/#0D is used to probe the "current" location, and is set to #OC=#FF (1.1 ROM at #FA22) and #0D=#03 (at #FA3A).
The next instruction is inside the test loop, which increments the pointer. So RAM is only tested from #0400 upward to end of memory (set by pointer in #0E,#0F) which terminates at #C000 or #4000 (for 48k or 16k computer).
This means the first 4 pages of memory go untested, as does "shadow" memory.
Unless you do a non-destructive memory test, it's hard to test page 0 when you're already using it for pointers. Same applies for page 1 (stack) which is already in use by this point. Page 3 is a mystery, as all sorts of hardware overlays that (at very least, the VIA chip), so testing that is impossible, as is the shadow RAM, inaccessible to a lone Oric with no hardware assistance.
Tested memory is always left with 0x55 ("U"), but the value in un-initialized memory is not reliable, because although if the DRAM chips are assumed to be all discharged, that doesn't guarantee all 0's or all 1's -- simply because the internal construction of a DRAM chip almost always involves some bits being stored as true logic, others as inverted logic. This is at the whim of the designer of the chip.
Always initialize your variables
Re: 3D Fongus with Erebus : does not load
That's why some values stored at page 0,1,2 are always there even if the selfdestruction code is used (CALL#F88F)
Re: 3D Fongus with Erebus : does not load
There was also the case with Asteroids from Arctic Computing, which worked on some Oric-1, and not others.
Apparently due to some bad PSG programming... And remember how Twilighte's samples worked on some Orics and not others.
Apparently due to some bad PSG programming... And remember how Twilighte's samples worked on some Orics and not others.
Re: 3D Fongus with Erebus : does not load
Thanks a lot to all of you, I will check the boot patterns. But there is something I don't understand : when you power off a computer, the RAM content disappear, isn't it ?
Re: 3D Fongus with Erebus : does not load
Another thing I experienced is some Twilighte keyboard reading routines not working on my Oric, at least those in Zip&Zap, if I remember correctly. Some keys do not respond, other respond quite randomly (not always detected, and/or detecting different values from the actual key pressed).
Yes, but it is what Mike said a couple of posts back: the contents are not 0s or 1s... or not always
That means that you cannot guarantee a given value at an address in zero page. If you store a flag in #0000, for instance, meaning 0 = keyboard, 1 = joystick and you do not initialise it, only change its value when the user selects joystick/keyboard control from the menu, it may start with keyboard control on most Orics, but with joystick in other machines...mikeb wrote: ↑Mon Jun 08, 2020 6:12 pm [...] although if the DRAM chips are assumed to be all discharged, that doesn't guarantee all 0's or all 1's -- simply because the internal construction of a DRAM chip almost always involves some bits being stored as true logic, others as inverted logic. This is at the whim of the designer of the chip.
- mikeb
- Flight Lieutenant
- Posts: 282
- Joined: Wed Sep 05, 2018 8:03 pm
- Location: West Midlands, UK
- Contact:
Re: 3D Fongus with Erebus : does not load
Assuming a complete power down, and all charge drained away from the DRAM chips, the raw transistor/capacitor cells will all be discharged (same state), yes.
Whether these are interpreted as 1's or 0's is down to the chip designers. You'd need to stare at the data sheet for a typical 4164 chip to see mention of this (and other delights such as row and column address scrambling!)
When you write a zero, and get a zero back (or a 1 and get a 1 back) then as far as you're concerned, from outside the chip, everything is fine.
Internally, the chip may store some of your logic inverted on the way in, and then again on the way out. This cancels out. You don't notice
The only time you notice it is when the chip is powered on, (all cells same state). Some bits are inverted on reading them back, and it contains an apparent pre-loaded pattern of 1's and 0's. This pattern is not 100% reliable, and very much depends on the chip manufacturer.
Below: From a Hyundai 4164 datasheet, shows that half of the data stored (rows 0 to 127) are stored as straight logic, and (128 to 255) are stored as inverted logic
- Attachments
-
- 1.png (15.32 KiB) Viewed 5551 times
Re: 3D Fongus with Erebus : does not load
When the keyboard is browsed directly a delay is required between the writing of the i/o register and reading the value, it is about the analogic device on the keyboard pcb wich is slower than the processor timing.Chema wrote: ↑Tue Jun 09, 2020 9:48 am Another thing I experienced is some Twilighte keyboard reading routines not working on my Oric, at least those in Zip&Zap, if I remember correctly. Some keys do not respond, other respond quite randomly (not always detected, and/or detecting different values from the actual key pressed).
Re: 3D Fongus with Erebus : does not load
Sorry guys, I met another game loading problem ...
This time, this is with "Harrier Attack". I tried 5 different releases :
https://www.oric.org/software/harrier_attack-52.html
on this site I tried both Oric-1 and Atmos releases, but when I load the game , for the Atmos version I see the Harrier Attack screen with "Loading" and "Please wait" on top of the screen. For the Oric-1 version, same thing but no "Loading", just "Please wait". Of course, nothing happens, even after having waited for more than 15 minutes ...
https://www.planetemu.net/rom/tangerine ... software-2
the release from this site does the same thing than the Atmos version of the previous site.
http://www.gametronik.com/site/fiche/or ... 520Attack/
the release from this site does the same thing than the previous site.
http://www.skarstad.net/oric/archive.html
Same issue here.
Is it working for you with an Erebus ?
This time, this is with "Harrier Attack". I tried 5 different releases :
https://www.oric.org/software/harrier_attack-52.html
on this site I tried both Oric-1 and Atmos releases, but when I load the game , for the Atmos version I see the Harrier Attack screen with "Loading" and "Please wait" on top of the screen. For the Oric-1 version, same thing but no "Loading", just "Please wait". Of course, nothing happens, even after having waited for more than 15 minutes ...
https://www.planetemu.net/rom/tangerine ... software-2
the release from this site does the same thing than the Atmos version of the previous site.
http://www.gametronik.com/site/fiche/or ... 520Attack/
the release from this site does the same thing than the previous site.
http://www.skarstad.net/oric/archive.html
Same issue here.
Is it working for you with an Erebus ?
Re: 3D Fongus with Erebus : does not load
Maybe try this one?
viewtopic.php?f=22&t=1957&hilit=harrier&start=15#p19580
I can't recall exactly but I think Harrier Attack might have some code playing with loading routines… Quite hazy memory though, I may be wrong.
viewtopic.php?f=22&t=1957&hilit=harrier&start=15#p19580
I can't recall exactly but I think Harrier Attack might have some code playing with loading routines… Quite hazy memory though, I may be wrong.
Re: 3D Fongus with Erebus : does not load
Thanks a lot for this link, unfortunatly I get the same result : the game freezes on the "loading" screen.
Re: 3D Fongus with Erebus : does not load
The zero page is deleted in the first block of the game, I put two NOP, try this
- Attachments
-
- HARRIERm.TAP
- (11.45 KiB) Downloaded 346 times
Re: 3D Fongus with Erebus : does not load
Thanks a million Kenneth, once again, you modified a game and now it works fine ! You're great !