Oriculator (WIP)
@Brana
I doubt it works on anything older than Win2000, however, if someone compiles it with an old enough GCC and a version of SDL that works on Win98, it would work. That won't be me, though, I haven't used a Win9x computer in a LOOOOOONG time.
@Everyone
Thought i'd post an update in this thread since the Oric-1 16k thread went a bit off topic
I fixed the toxic slime bonus bug. No progress yet on the strange sedoric problems.
I doubt it works on anything older than Win2000, however, if someone compiles it with an old enough GCC and a version of SDL that works on Win98, it would work. That won't be me, though, I haven't used a Win9x computer in a LOOOOOONG time.
@Everyone
Thought i'd post an update in this thread since the Oric-1 16k thread went a bit off topic
I fixed the toxic slime bonus bug. No progress yet on the strange sedoric problems.
Some info on the sedoric bug...
The disk debug in Oriculator includes the address of the instruction that writes to the disk command register for each disk operation. When booting the toxic slime disk, there are 2 distinct disk routines before the "filling memory" message:
A) The microdisc rom code (instruction at $EA31 writes to the command register)
B) SEDORIC ($b966)
The routine at A executes identically from cold boot or reset, and passes control to the next phase.
The routine at B uses the X register to count down how many sectors to read from the disk. If i run oriculator, set a breakpoint at $b966, then insert the toxic slime disk, the first execution of $b966 has 4 in X, so only 4 sectors are read. Upon reset, at the same point, X is $3C.
If I start Oriculator, set a breakpoint at $b966, insert the toxic slime disk, and then change X to $3C, clear breakpoints and exit the debugger, the toxic slime disk boots and runs flawlessly without any resets.
So all we need to do now is reverse engineer the code that sets up X as the number of sectors to read and figure out why it fails from cold boot.
The disk debug in Oriculator includes the address of the instruction that writes to the disk command register for each disk operation. When booting the toxic slime disk, there are 2 distinct disk routines before the "filling memory" message:
A) The microdisc rom code (instruction at $EA31 writes to the command register)
B) SEDORIC ($b966)
The routine at A executes identically from cold boot or reset, and passes control to the next phase.
The routine at B uses the X register to count down how many sectors to read from the disk. If i run oriculator, set a breakpoint at $b966, then insert the toxic slime disk, the first execution of $b966 has 4 in X, so only 4 sectors are read. Upon reset, at the same point, X is $3C.
If I start Oriculator, set a breakpoint at $b966, insert the toxic slime disk, and then change X to $3C, clear breakpoints and exit the debugger, the toxic slime disk boots and runs flawlessly without any resets.
So all we need to do now is reverse engineer the code that sets up X as the number of sectors to read and figure out why it fails from cold boot.
OK, so i've worked out the sequence of code leading up to the $B966 instruction:
It seems to me that it only works after a reset because before jumping into the sea of BRKs, it sets up the interrupt vector to point to $d0a5. Then, when you reset Oriculator, that vector changes the checksum calculated in step 8 to be non-zero, so on the second time through, steps 11, 12 & 13 are executed, and X contains $3C instead of $04, and a lot more sectors are therefore read from the disk.
So this raises three questions:
1. What is *supposed* to be @ $c980 to be checksummed?
2. Why isn't it there?
3. Why does anything at all being in overlay RAM make it read $3C sectors instead of $04?
And the only answers I have right now are "I don't know".
Edit: Could someone who knows their way around euphoric's debugger boot the toxic slime disk, break @ $b92e and dump the contents of $c980-$ffff ?
Code: Select all
1. ($b902-$b902) Disable interrupts
2. ($b903-$b905) Disable VIA interrupt
3. ($b906-$b90f) Store the address $0710 into $26b/26c
4. ($b910-$b914) $314 write:
- Disable microdisc ROM
- Enable ROM
- Set bit 2 (?)
5. ($b915-$b91b) Print the sedoric info (string at $b9ba)
6. ($b91c-$b920) Enable overlay RAM (romdis=1,eprom=0)
7. ($b921-$b92d) Copy 3 bytes from $ccfd to $ccf7
- First boot = 00 00 00
- Reset = 00 00 00
8. ($b92e-$b941) Calculate 8-byte checksum of $c980 to $ffff
- First boot = All zeros
- Reset = All zeros except "a5 d0" @ $fffe
9. ($b942-$b943) Load X with 4, transfer the checksum to Y
10. ($b944-$b945) If the checksum is zero, jump to $b94e
11. ($b946-$b949) Load A&Y with the contents of $b901
12. ($b94a-$b94b) If non-zero, jump to $b94e
13. ($b94c-$b94d) Load X with $3C
14. ($b94e-$b94f) Store Y at $0000
15. ($b950-$b959) Set the vector at $fffe to $b97b
16. ($b95a-$b95e) Set sector register to 5
17. ($b95f-$b963) Enable disk interrupts
18. ($b964-$b968) Send "read sector" command
19. ($b969-$b96b) Set Y to zero, enable interrupts
20. ($b96c-$b97a) Read all bytes that appear on the disk
data register until we're interrupted
So this raises three questions:
1. What is *supposed* to be @ $c980 to be checksummed?
2. Why isn't it there?
3. Why does anything at all being in overlay RAM make it read $3C sectors instead of $04?
And the only answers I have right now are "I don't know".
Edit: Could someone who knows their way around euphoric's debugger boot the toxic slime disk, break @ $b92e and dump the contents of $c980-$ffff ?
Right, well, what this tells me is that the boot sequence definately goes wrong before the sedoric logo appears and the second phase takes over (because by the time the sedoric logo appears, we should have stuff at $c980, and we dont'). Which means the fault happens when oriculator is executing the microdisc rom. So I guess I should go back try again at disassembling that rom.
I don't think so. I'm pretty sure i'm handling that correctly. Anyway, i'm continuing my previous work of making a commented disassembly of the microdisc ROM. The only reason I stopped was because when investigating the "reset seems to fix it" behaviour, it seemed to point to the sedoric code, but that was a red herring.
Edit: In fact, I know my overlay ram/disk rom stuff is right becuse the microdisc rom wouldn't even get past the ramtest it does right at powerup otherwise.
Edit: In fact, I know my overlay ram/disk rom stuff is right becuse the microdisc rom wouldn't even get past the ramtest it does right at powerup otherwise.
Xeron, try there
http://andre.cheramy.net/telechargement/sedoricnu3.pdf
and see page 517.
There's a commented disassembly of the Microdisc eprom (in English).
hope this helps !
EDIT: also available here in TXT:
http://oric.ifrance.com/oric/hardware/eprom.txt
http://andre.cheramy.net/telechargement/sedoricnu3.pdf
and see page 517.
There's a commented disassembly of the Microdisc eprom (in English).
hope this helps !
EDIT: also available here in TXT:
http://oric.ifrance.com/oric/hardware/eprom.txt
Mile is this doc in thé Oric library?
hi Mike,
Mile is this doc in your Oric library?
Mile is this doc in your Oric library?
Symoon wrote:Xeron, try there
http://andre.cheramy.net/telechargement/sedoricnu3.pdf
and see page 517.
There's a commented disassembly of the Microdisc eprom (in English).
hope this helps !
EDIT: also available here in TXT:
http://oric.ifrance.com/oric/hardware/eprom.txt
/kml
skype pseudo : kamelitoloveless
skype pseudo : kamelitoloveless
I've just uploaded a new WIP build. No progress at all with the disk stuff, but i've added some commandline options.
The download is here (SVNr63)
You can see the commandline options here (or just read ReadMe.txt after downloading the WIP build).
The download is here (SVNr63)
You can see the commandline options here (or just read ReadMe.txt after downloading the WIP build).