|
From an earlier post, I've been working to get an initial BIOS extension for a DS1511 Realtime Clock and a Compact Flash in True IDE mode added to my C02 Pocket SBC. The first version of the adapter board has passed tests and is working as designed. I can access all registers of the DS1511 and the CF-Card without issue. I also wrote a handful of routines to access both of these devices for core capabilities.... so far, so good.
Next is to integrate both of these hardware devices into the next version of the BIOS. Working in a small memory foot print, I'm looking to minimize the code space to get everything working. As the additional hardware devices are on a separate adapter card which is plugged into the main board with a 30-pin ribbon cable, I'm writing routines to detect each of these new devices before attempting to access them. It's a different challenge than writing the routines to support them for their core functions. I've come up with a method for each one, but I'm sure others have done similar things in an attempt to sense a if a device is there and then go and initialize it for use.
For the DS1511 RTC, I've decided to use the 256 bytes of NVRAM as an identity by loading a two-byte signature in the last two locations. So after a reset of the C02 Pocket SBC, once the onboard UART and associated routines have been setup, I load the NVRAM into a page of memory. I then check for the two-byte signature. If the signature is there, I'll continue and setup the software RTC by reading the values from the DS1511 for the date and time (which are in BCD), convert them into binary and load these into an updated RTC code (ISR) and the current date and time are now setup. If the two-byte signature is not found in the NVRAM load, there's of course two possibilities: 1- The NVRAM hasn't been setup with the signature, or 2- The DS1511 isn't physically connected to the bus. In this case, I just preload the EPOCH time as s start for the software RTC maintained in BIOS. Granted, this does require that the DS1511 RTC gets initialized for both the actual time and date and the NVRAM is initialized by setting up the two-byte signature. I also send a message to the terminal of "RTC Found" to notify that the RTC has in fact been used to load the software RTC.
For the Compact Flash card, it's a more odd process. I quickly found out that the time for the CF-Card to complete it's internal startup after a reset is greater than the overall time to setup the initial BIOS (clear Page Zero, setup software vectors and initialize the UART's timer, transmit and receive interrupts, etc. and even load the RTC clock from the DS1511. The main problem was how to determine if the CF-Card was actually plugged in. Note that the CF-Card socket has two outer pins that are grounded when the card is plugged in, but the adapter design doesn't use these for anything. It would also have required some additional hardware to sense these, so I opted not to. Also, you can't simply load the status register and check for drive ready or busy... as these are bits in the status register which would never toggle unless an actual CF Card is plugged in.
As all of my I/O space is in page $FE, all reads to I/O addresses will return a $FE if there is nothing at the specific hardware address (which is a memory location for the 6502). I opted to use this phantom address read to determine if the CF Card is plugged in or not. If the status register read is a $FE, I simply exit back to the BIOS cold start routine. If the read is not a $FE, I sense the Busy flag in the status register and wait for it to become inactive. One that completes, I send a reset/recalibrate command to the drive, followed by the command to run internal diagnostics. I check the status register to ensure that both commands executed correctly and continue setting up the CF Card, which includes adding the ISR routine for the card into the core ISR and send an init message of "IDE Found" to the terminal. It's a noticeable delay when sensing the IDE controller when powering up the system, but this procedure has worked well so far.
Not sure if anyone else has done something similar, but this is what I've come up with so far. I've got the main BIOS completed for the DS1511, which is really only a few routines: Read the NVRAM, Write the NVRAM and Read the DS1511 and set the software RTC maintained by the BIOS. As far as setting the RTC, I'll have a separate utility that can be loaded via Xmodem-CRC (which the C02 Monitor supports). This keeps the BIOS code size down.... also, one shouldn't be needing to set the Time and Date of the DS1511 on a regular basis. For the IDE controller (CF Card), I'm still working on the core code to initialize the card for LBA size and integrating the read, write, verify routines into the ISR.
The ISR is more difficult to design and implement. as there's no actual status bit you can read to determine IF the IDE controller did in fact generate an interrupt. Also, reading the main status register resets any interrupt condition. The IDE controller for the CF Card generates an interrupt for any read command to start the actual reading from the card. When writing to the card, you need to poll the card for the DRQ line, then load the buffer. After the buffer is loaded and written, the CF Card might generate an interrupt after the write is done. I say might as the specification from SanDisk leads me to believe that the interrupt is only generated if a multiple block write has been initiated, and the CF Card will generate an interrupt after each block is written, thereby requesting the next block of data from the host.
I'm hoping to have an initial BIOS completed soon... but I've got multiple irons in the project fire right now.... so either late nights or early mornings is when I'm getting around to this.
|
Login
Register
FAQ
Search
