[Coco] ROM Cart registers

[Mark Marlette]

Jim,

<<<<<snip...snip...too hard to follow....>>>>>



> As I watch the list and the thread out of the corner of my eye, I thought you indicated that your MPI was functional?
It is, as far as I have thus tested it before my query.    However, I 
did just test booting from slot #3 (sIDE), moving the switch to #1, and 
the cursor dies (it appears to lock up).  I previously assumed that the 
HDB-DOS was hooking the interpreter and when I move the switch, the cts 
signal no longer reaches the sIDE boot rom and thus the machine locks 
up.  Are you stating that I should be able to move the switch and this 

type DIR in the basic interpreter and not have it lock up?
-------------------------
correct, no lock should occur.

-------------------------
>>  From your posts here and questions of SLENB~, I wonder if the sIDE works in your device?
it does.  I save and load files from the CF card with ease, and HDB DOS 
1.1b boots when slot 3 is selected on boot.
>
> A true test is backing up a device with verify in your MPI. We tested 12-24hrs, without an error, many times.
You mean backing up a floppy disk, I assume.  I need to buy or somehow 

secure a FDD mech to do so.  I have the FD500, but no mech at present.
-------------------------
No,I mean something large, 12-24hr bit test. 

-------------------------
>> The current generation goes ~300% faster. So if your MPI won't run the sIDE, it will not run Cloud-9's Gen 3 devices.
Well, it's not failing under load.  It's just that I was surprised that 
the sIDE registers show up all the time, no matter the slot.

And, though I am still learning about SCS, it does appear the sIDE ignores the presence of the SCS signal and responds on the bus whenever 
$ff50-$ff5f is accesses, no matter the state of the MPI slot register, 
as you note above.

I was under the impression that if the SCS signal was not triggered on a 
particular slot, that slot should not respond to $ff40-$ff5f accesses.
------------------------
I am not surprised as it is not decoded with a slot. No need to, the device and driver are slotless, fully decoded. IIRC so is the Glenside IDE. There are NO issues with any floppy disk controller that we tested using this method and I had almost all of them at the time.

-------------------------
In any event, since I assume miniFlash uses the same basic firmware as 
sIDE with respect to $ff59, I am trying to determine how a ?peek($ff59) 
will respond in such a situation.  IN my case, trying to read any 
register from $ff50-$ff5f in slot #0 while the sIDE is in slot #3 does 
not return correct information.  I assume that's because my register 
outputs are fighting with the register outputs of the sIDE.
-------------------------

The miniFlash is a subset of the sIDE's logic, so yes, it will be the same.

You have a conflict, the sIDE has requested that ALL devices be removed from the bus via SLENB~. You are not complying to this request, thus you are not following the rules for the signal.

It is not a question of why I used the signal in that manner, but why you are not complying to the request to remove your device from the bus?

This method is used for reasons for future products, advanced signaling which are being used currently. This was a platform to prove certain requirements for future designs and having commonality across those designs.

This signaling method is allowed in all of the Tandy MPIs. You are trying to make a compatible device follow the bus rules and don't get stuck on why I did what I did.


Do you have a Tandy MPI? You could answer a lot of your own questions... ?????


When you can run the sIDE as it was designed, software select, switch slot selects in your MPI design, back up data for 12-24 hours without data loss, then you will be there.

Regards,

Mark
www.cloud9tech.com

-----------------------
Jim
-- 
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco