[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Decoding RamFactor's memory detection
So that means there IS no ram size detection? That's just bonkers!
I'll have to fire up a real machine with a ramfactor (hope mine still works) to see what the behavior is on a 1meg card (which is what I have.)
There are no I/O accesses other than 0,1,2 (which set the slinky address), 3 (which is the read/write address) and F which is the bank select. I don't see any other I/O traffic being used to read the card so I suppose the firmware tries to load/store values at different spots to see what sticks. I'll have to disassemble the MLI routine since X and Y return the device size.
There is only one other feasible answer and that is the device creates a partition map on power up which indicates the block sizes and so on. I know that the first call to the firmware (PR#s) shows a blank partition map and that does not match the expected behavior of the card which should have a blank partition containing all the RAM in it on start -- at least that's my interpretation of the manual.
The only other think I'll need to research is why it is doing alternate read/writes to the slinky ram. Each read/write is supposed to increment the pointer but it doesn't seem right that it would write a byte, read a bye and then write a byte afterwards. My two theories on this are that 1) My CPU implementation on one or more opcodes might be crap and triggering read events on ram when they shouldn't (causing extra I/O accesses) or 2) The ramfactor firmware works in very very very strange ways that I don't understand yet.
ugh.
It was easy enough doing the "slinky ram" part of it at least. And that's all I need to cram a 1meg card full of data to run a demo. ;-)
-B
On Thursday, August 16, 2012 8:53:21 AM UTC-5, Hot Rod wrote:
> On Thursday, August 16, 2012 8:32:58 AM UTC-5, BLuRry wrote:
>
> > Or rather I'm attempting to decode it anyway so I can get the bugs out of my RamFactor emulation code. I've traced the screen write portion of the diagnostic routine and found where it starts writing "256" to the screen. The question is, how is it getting the value for "2" to display?
>
> >
>
> >
>
> >
>
> > A0 03 00 01F2 ..R...Z. cbcc : DEX
>
> >
>
> > A0 02 00 01F2 ..R..... cbcd : BPL $cb9f
>
> >
>
> > A0 02 00 01F2 ..R..... cb9f : LDA #$00
>
> >
>
> > 00 02 00 01F2 ..R...Z. cba1 : PHA
>
> >
>
> > 00 02 00 01F1 ..R...Z. cba2 : SEC
>
> >
>
> > 00 02 00 01F1 ..R...ZC cba3 : LDA $3e
>
> >
>
> > 00 02 00 01F1 ..R...ZC cba5 : SBC $cbde,X
>
> >
>
> > 70 02 00 01F1 ..R..... cba8 : PHA
>
> >
>
> > 70 02 00 01F0 ..R..... cba9 : LDA $3f
>
> >
>
> > 04 02 00 01F0 ..R..... cbab : SBC $cbe3,X
>
> >
>
> > 02 02 00 01F0 ..R....C cbae : BCC $cbba
>
> >
>
> > 02 02 00 01F0 ..R....C cbb0 : STA $3f
>
> >
>
> > 02 02 00 01F0 ..R....C cbb2 : PLA
>
> >
>
> > 70 02 00 01F1 ..R....C cbb3 : STA $3e
>
> >
>
> > 70 02 00 01F1 ..R....C cbb5 : PLA
>
> >
>
> > 00 02 00 01F2 ..R...ZC cbb6 : ADC #$00
>
> >
>
> > 01 02 00 01F2 ..R..... cbb8 : BNE $cba1
>
> >
>
> > 01 02 00 01F2 ..R..... cba1 : PHA
>
> >
>
> > 01 02 00 01F1 ..R..... cba2 : SEC
>
> >
>
> > 01 02 00 01F1 ..R....C cba3 : LDA $3e
>
> >
>
> > 70 02 00 01F1 ..R....C cba5 : SBC $cbde,X
>
> >
>
> > E0 02 00 01F1 NVR..... cba8 : PHA
>
> >
>
> > E0 02 00 01F0 NVR..... cba9 : LDA $3f
>
> >
>
> > 02 02 00 01F0 .VR..... cbab : SBC $cbe3,X
>
> >
>
> > 00 02 00 01F0 ..R...ZC cbae : BCC $cbba
>
> >
>
> > 00 02 00 01F0 ..R...ZC cbb0 : STA $3f
>
> >
>
> > 00 02 00 01F0 ..R...ZC cbb2 : PLA
>
> >
>
> > E0 02 00 01F1 N.R....C cbb3 : STA $3e
>
> >
>
> > E0 02 00 01F1 N.R....C cbb5 : PLA
>
> >
>
> > 01 02 00 01F2 ..R....C cbb6 : ADC #$00
>
> >
>
> > 02 02 00 01F2 ..R..... cbb8 : BNE $cba1
>
> >
>
> > 02 02 00 01F2 ..R..... cba1 : PHA
>
> >
>
> > 02 02 00 01F1 ..R..... cba2 : SEC
>
> >
>
> > 02 02 00 01F1 ..R....C cba3 : LDA $3e
>
> >
>
> > E0 02 00 01F1 N.R....C cba5 : SBC $cbde,X
>
> >
>
> > 50 02 00 01F1 ..R....C cba8 : PHA
>
> >
>
> > 50 02 00 01F0 ..R....C cba9 : LDA $3f
>
> >
>
> > 00 02 00 01F0 ..R...ZC cbab : SBC $cbe3,X
>
> >
>
> > FF 02 00 01F0 N.R..... cbae : BCC $cbba
>
> >
>
> > FF 02 00 01F0 N.R..... cbba : PLA
>
> >
>
> > 50 02 00 01F1 ..R..... cbbb : PLA
>
> >
>
> > 02 02 00 01F2 ..R..... cbbc : BNE $cbc6
>
> >
>
> > 02 02 00 01F2 ..R..... cbc6 : INY
>
> >
>
> > 02 02 01 01F2 ..R..... cbc7 : EOR #$b0
>
> >
>
> > B2 02 01 01F2 N.R..... cbc9 : JSR $fded
>
> >
>
> > //------------------------------------------ WRITES 256k where A is '2'
>
>
>
> So that last JSR is to the ROM routine for a charout (I think), and to get a '2', it is being called with #$B2 in the accumulator.
>
>
>
> The #$B2 is a result of the EOR of #$B0 with the value in A (which was a #$02 at the time).
>
>
>
> The accumulator ends up with a #$02 in it, because of the two ADC #$00 ops on it, each time having the carry bit set from the ops that precede those. The accumulator was init'd with #$00, and on each 'second' PLA (when it's pulled off the stack) and the ADC #$00 is performed, the carry bit is evidently set, resulting in first #$01, and then #$02. Then this is EOR'd with #$B0, and you get #$B2 sent to the $FDED routine (and a '2' on the screen).
>
>
>
> (I'm still pretty rusty on this!)
>
>
>
> ]HR