CRU scan sample code

[+retroclouds]

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.

 

 

[Stuart]

If you look at the code at http://www.stuartconner.me.uk/ti/ti.htm#tipi_network_socket_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 November 4, 2018 by Stuart

[+Lee Stewart]

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

[+InsaneMultitasker]

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.

[+retroclouds]

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.

[+retroclouds]

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 Disk Controller sidecar
• TI RS232/PIO card
• TI RS-232 interface sidecar
• 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 November 17, 2018 by retroclouds

[Opry99er]

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 November 12, 2018 by Opry99er

[+retroclouds]

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 November 12, 2018 by retroclouds

[+retroclouds]

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.

[+InsaneMultitasker]

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.

[apersson850]

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.

[+retroclouds]

Now that my daily driver TI-99/4a console is working again I've added some more devices to the scan (previous post updated).

 

* TI Disk Controller sidecar

* TI RS-232 interface sidecar

[RXB]

 

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.

Easy way in XB is just

1) CALL INIT

2) Turn on CRU >1E00 and write 30 to >4004 (going to need Assembly for this in XB, RXB has SAMS support built in)

3) check if >2000 has >00 or >20 there with a CALL PEEK(8192,X) so if X=0 SAMS works, if X=32 no SAMS

[+retroclouds]

Here's the first version of my device scan program. It's an 8K ROM and runs completely in scratchpad ram, so no 32K expansion required.

 

DSRSCANC.BIN

 

It can currently identify the following devices:

 

Real devices:

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

Emulation:

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

Device identification is done based on a CRC-16 (Cyclic Redundancy Check) of the 1K block at >4000->43ff. The checksum of that block of memory is shown in the column CRC2. Note that I also do a CRC-16 check on the 8K block at >4000->5fff, (column CRC1) but it's currently not used for device indentification.

I would like to add the checksums for more devices to this program.

So if you're willing to help. Please add the checksums (value in column CRC1 and CRC2) to this thread, telling what device it belongs to.

I can then add the appropriate identification strings to the program.

Note that Device identification currently is purely based on CRC-16, so for devices that do not have a DSR (e.g. SAMS) or have a self-modifying DSR (HRD ramdisk) are not properly recognized at this time.

Oh and as always, use at your own risk.

Edited November 18, 2018 by retroclouds

[+Ksarul]

Looks like I need to burn a cartridge and have some extended testing fun. . .as soon as I have some spare cycles! Thanks for starting this one up!