16k Oric-1
For what I can see, now the only (big) remaining issue is Sedoric disks:
- they fail booting on first attempt
- they boot and display the boot menu after a reset - and then the oric freeze
Visually, the only other bug I can see is the strange behavior of the bonus countdown in Toxic Slime. Wish I had the source code, woul allow to find more easily what the code is actually trying to do, would help solving the emulator issue.
- they fail booting on first attempt
- they boot and display the boot menu after a reset - and then the oric freeze
Visually, the only other bug I can see is the strange behavior of the bonus countdown in Toxic Slime. Wish I had the source code, woul allow to find more easily what the code is actually trying to do, would help solving the emulator issue.
Hi everyone. I have tested space:199 with the latest build of oriculator. It only uses sedoric to boot, then run the inist statement which in turn runs a basic loader that sets paper color, goes into hires and loads either the intro or the game depending on a value in memory.
The tests where as follows.
First run. Prints sedoric v3.0 message and, as before halts on a BRK at position d0a5 .
First reset. Prints sedoric v3.0 runs the inist and loads the intro. First graphic is displayed (ITC logo). No sound and oric seems inside an infinite loop. From what I see the problem is that the irq routine is not working properly. It should decrement a variable called _TimerCounter which is used to make the main program wait for a given time. This is not done, so the wait function never ends. Also if the irq routine is not working, that would explain why sound is not heard either.
The address of the irq routine is correctly set at fffe-ffff, but it seems it is never called (I issued a bs 1b39 and never got a break there)
Second reset. System boots. Memory is not refreshed, so a given byte now contains a value which indicates the basic loader to run the game. It is loaded. Also overlay seems correctly initialized (at least it looks like so). The initial screen and scroll text are displayed and work correctly, but still no sound. Also keyboard not responding, which also points to the irq routine. Again the correct address is in fffe-ffff ($8006) but that is never called.
(BTW, issuing a bs 8006 returns 01: $1f46, what does that info mean?)
Third reset... gets back to intro and ITC logo, so the basic loader finds the memory position again with the initial value (?)
Fourth reset.. agan the game is run, as in the second reset and so on.
The basic loader is:
Position $9fff should be anything byt 69 the first time the system is booted, but remains as 69 at any subsequent reboots as that memory is unchanged (not re-running the emulator, which reinitializes that address).
Just (again) in case this rings bells in someone's head
The tests where as follows.
First run. Prints sedoric v3.0 message and, as before halts on a BRK at position d0a5 .
First reset. Prints sedoric v3.0 runs the inist and loads the intro. First graphic is displayed (ITC logo). No sound and oric seems inside an infinite loop. From what I see the problem is that the irq routine is not working properly. It should decrement a variable called _TimerCounter which is used to make the main program wait for a given time. This is not done, so the wait function never ends. Also if the irq routine is not working, that would explain why sound is not heard either.
The address of the irq routine is correctly set at fffe-ffff, but it seems it is never called (I issued a bs 1b39 and never got a break there)
Second reset. System boots. Memory is not refreshed, so a given byte now contains a value which indicates the basic loader to run the game. It is loaded. Also overlay seems correctly initialized (at least it looks like so). The initial screen and scroll text are displayed and work correctly, but still no sound. Also keyboard not responding, which also points to the irq routine. Again the correct address is in fffe-ffff ($8006) but that is never called.
(BTW, issuing a bs 8006 returns 01: $1f46, what does that info mean?)
Third reset... gets back to intro and ITC logo, so the basic loader finds the memory position again with the initial value (?)
Fourth reset.. agan the game is run, as in the second reset and so on.
The basic loader is:
Code: Select all
5 PAPER0:INK0
10 IF PEEK(#9FFF) <> 69 THEN 30
20 HIRES:!SP99.COM
30 POKE #9FFF,69
35 HIRES
40 !SPINTRO.COM
Just (again) in case this rings bells in someone's head
Ahhh.. Ok.Xeron wrote:You have to put a '$' before numbers in the debugger to specify hex, otherwise it treats it as decimal. You can also use % for binary.
I dunno if i should change it to default to hex.
Anyway, you were probably setting breakpoints at wrong addresses because of this. Please re-try your tests.
Just tested it and the same thing happens. I cannot see the IRQ routine being called, even stepping through the code for a while.
The I flag seems to be cleared (=0).
Any ideas? Maybe I am doing something wrong?
Well, the VIA is used for many things in the Oric, so possibly Sedoric set it to a particular mode for doing loading, and for some reason it could leave the VIA in a particular (incorrect) state leading to things like the keyboard irq/blinking cursor not working anymore.Xeron wrote:What makes you think of VIA?
I'm looking at VIA.C, and I'm wondering about something in Timer 1 tick-tock:
if (line 363) the 'if( v->t1run )' is not executed, you still do the v->t1c-=cycles (line 372), is it possible this underflows ?
Same thing lines 397 and 405 for tc2.
Also there is an "init" method, but the "reset" is not implemented, is this on purpose?
Since I'm not an expert on VIA programming at all (ie: I suck) I may be totally wrong, I fear that only Twilighte can help there.
if (line 363) the 'if( v->t1run )' is not executed, you still do the v->t1c-=cycles (line 372), is it possible this underflows ?
Same thing lines 397 and 405 for tc2.
Also there is an "init" method, but the "reset" is not implemented, is this on purpose?
Since I'm not an expert on VIA programming at all (ie: I suck) I may be totally wrong, I fear that only Twilighte can help there.
Do not fear.. Twilighte is here!
ok not so available these days but i keep promising to take a look at Oriculator observing its way it emulates the VIA and handles irq's. I did mention a little while ago i thought the problem may lie with IRQ's :{P
I have a wondrous 2 weeks of bliss coming up so i'll try to fit this in somewhere.
ok not so available these days but i keep promising to take a look at Oriculator observing its way it emulates the VIA and handles irq's. I did mention a little while ago i thought the problem may lie with IRQ's :{P
I have a wondrous 2 weeks of bliss coming up so i'll try to fit this in somewhere.
From memory, this is on purpose and should be what the VIA itself does (as described by the MOS datasheet). The t1c field is an unsigned short and it wraps around, which is what the VIA counter does.Dbug wrote: if (line 363) the 'if( v->t1run )' is not executed, you still do the v->t1c-=cycles (line 372), is it possible this underflows ?
Again this is from memory, but I do remember being very careful to make this work as it does in the datasheet.
Hmm... thats interesting. I maybe intended to do something in the reset but forgot about it.Also there is an "init" method, but the "reset" is not implemented, is this on purpose?