Jump to content

Photo

CRU scan sample code

CRU device scan tms9900

10 replies to this topic

#1 retroclouds ONLINE  

retroclouds

    Stargunner

  • 1,652 posts
  • Location:Germany

Posted Sun Nov 4, 2018 2:15 AM

Do we have sample code showing how to do a device CRU scan.

 

What I would like to accomplish is scan and identify peripheral expansion cards like HRD3000, RS232, SAMS, ...

Basically something like we have in the CFG834 configuration program.   

 

 



#2 Stuart OFFLINE  

Stuart

    Dragonstomper

  • 793 posts
  • Location:Southampton, UK

Posted Sun Nov 4, 2018 6:00 AM

If you look at the code at http://www.stuartcon...ocket_interface, starting at the line before label ISDSR, that steps through the CRU space looking for the TIPI DSR. Should be relatively easy to adapt code for what you're after.


Edited by Stuart, Sun Nov 4, 2018 6:02 AM.


#3 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,804 posts
  • Location:Silver Run, Maryland

Posted Sun Nov 4, 2018 7:05 AM

There is nothing in DSR space that can be guaranteed to identify a particular card.  For example, a TI disk controller card has the same first device name as a CorComp card, viz., “DSK”.  The device-name list can certainly help and is maybe all you need, particularly with a controller with a unique device name like “TIPI”, but TI’s DSR development guidelines do not require the card name or manufacturer to be present.

 

...lee



#4 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,278 posts

Posted Sun Nov 4, 2018 8:48 PM

The CFG834 routine looks for specific, unique device names to identify the majority of the peripherals.  For two or more devices with overlapping device names, the search order is important.  For example, the SCSI and HFDC cards both have "WDSx" devices but only the SCSI card has the "SCSx" device, thus we must look for SCSI then WDS.  Subprograms are another source of uniqueness that can be leveraged.   Horizon RAMdisks require a bit more inspection at the CRU and hardware level to determine the size and type.   Some peripherals do not have a DSR, such as the SAMS and MBP clock cards, so if you want to identify the you need to manipulate and test them using something besides a DSR check.



#5 retroclouds ONLINE  

retroclouds

    Stargunner

  • Topic Starter
  • 1,652 posts
  • Location:Germany

Posted Sun Nov 11, 2018 9:21 AM

There is nothing in DSR space that can be guaranteed to identify a particular card.  For example, a TI disk controller card has the same first device name as a CorComp card, viz., “DSK”.  The device-name list can certainly help and is maybe all you need, particularly with a controller with a unique device name like “TIPI”, but TI’s DSR development guidelines do not require the card name or manufacturer to be present.

 

...lee

 

ok, here's the idea. I've implemented a CRC-16 check in assembly language. 

I think that it should be possible to identify most of the DSR rom's by their checksum. What I'd like to do is collect a list of checksums for the most common devices.

 

Obviously you'd need to do more checking to identify the full characteristics of the device, e.g. to find out how much RAM a HRD has, etc.

Will see how it goes.



#6 retroclouds ONLINE  

retroclouds

    Stargunner

  • Topic Starter
  • 1,652 posts
  • Location:Germany

Posted Sun Nov 11, 2018 2:48 PM

So far I was able to successfully identify the following devices by doing a CRC-16 check on the DSR space:

 

Real devices:

  • TIPI Sidecar
  • TI Disk Controller card
  • TI RS232/PIO card
  • PGRAM+ card
  • MYARC RS232 Interface card model RSIC-1
  • nanopeb SIO
  • CF7+

 

Emulation:

  • Classic99 Controller (Disk/Clipboard/Clock)
  • JS99er Controller (Disk)

 

Still on my todo list (devices I own):

  • RS232-PIO Single-Step (TI Workshop)
  • CF7+   (in different flavours)
  • nanopeb SIO
  • Sidecar Disk Controller
  • Sidecar RS232

 

 

Basically I have 2 ways of doing the CRC-16 check:

  • CRC-16 check on >4000->5fff
  • CRC-16 check on >4000->43ff

 

To get a faster response I'm concentrating on the 2nd one.

 

Not sure where this is all is leading to, probably add it as a function to my spectra2 library.

But hey, it's about fun and learning stuff, so...

 

Will probably release my "scanner" as a cartridge image by the end of next week. That way, results can be cross-checked / verified.

Coming to think about it, would be cool to compile an online checksum list of the different DSR's flying around there.  ;)


Edited by retroclouds, Mon Nov 12, 2018 3:38 PM.


#7 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 9,966 posts
  • Location:Hustisford, WI

Posted Mon Nov 12, 2018 1:23 AM

I know the ROS/CFG package has a CRU scanning routine which identifies just about every legacy card that exists...

Might be worth looking into. :)


***EDIT***

Never mind.... looks like you're well aware. :)

Edited by Opry99er, Mon Nov 12, 2018 1:24 AM.


#8 retroclouds ONLINE  

retroclouds

    Stargunner

  • Topic Starter
  • 1,652 posts
  • Location:Germany

Posted Mon Nov 12, 2018 3:36 PM

I know the ROS/CFG package has a CRU scanning routine which identifies just about every legacy card that exists...

Might be worth looking into. :)


***EDIT***

Never mind.... looks like you're well aware. :)

 

Thanks for the heads up. Actually my CRC check works real well for those cards that do have a DSR on ROM/EPROM.

There are 2 cards I cannot identify via CRC, first being my HRD ramdisk and the other one is SAMS. 

 

The HRD has its DSR in RAM and it seems to overwrite parts of it quite often. Probably config settings. So no use doing checksums here.

The SAMS does not have a DSR, so hence can't CRC it.   I think that the SAMS is always at cru >1e00 so that should be good enough to identify it.


Edited by retroclouds, Mon Nov 12, 2018 3:40 PM.


#9 retroclouds ONLINE  

retroclouds

    Stargunner

  • Topic Starter
  • 1,652 posts
  • Location:Germany

Posted Mon Nov 12, 2018 3:45 PM

Bummer is that my daily driver TI-99/4a console (the only one with an F18a) started having some issues this evening.

 

The keyboard is no longer responding. This happened after I used one of my CF7+ devices.

Dunno, always had a strange feeling as far this TI-99/4a console is concerned playing together with the CF7+

Always had the feeling that the keyboard keys repeated too quickly while using the CF7+

I'm not sure if this really is a keyboard thing or if there's something else wrong (9901 issue?)

 

So further development will have to way for a while until I fixed the console.

Do have sufficient replacement parts/consoles. The only thing I don't want to do is transplant my F18a to another console. Will see how it goes.  ;)



#10 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,278 posts

Posted Mon Nov 12, 2018 4:53 PM

You might run into variants of some DSRs so you may need more than one CRC/checksum per peripheral card.  This is the main reason I stuck with testing for device names/subprograms when I updated the Horizon CFG program.   Some cards without a DSR include SID Blaster, MBP/Clulow clock cards, SAMS memory, and probably a few others I have forgotten :)  The Horizon does indeed modify its DSR space (RAM) as that is where its buffers, workspaces, configuration and flags are stored.



#11 apersson850 OFFLINE  

apersson850

    Dragonstomper

  • 513 posts

Posted Wed Nov 14, 2018 4:14 PM

The Horizon CFG program does a pretty good job. It even identifies my clock card as being a clock card, in spite of it being the only one sample in the world. I know that for sure, as I've designed and built it myself.

I think that I, by coincidence, happen to have the same name for a subprogram on that card as some other manufacturer put in their card at a later date.

But all my own cards have RAM in DSR space, so they'll not be possible to detect by any checksum either.







Also tagged with one or more of these keywords: CRU, device scan, tms9900

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users