6502.org

Well, I've changed the code and patterned it more after what BDD does... no difference. And yes, the idea of having the registers loaded with a time is to allow the user to xfer the registers over when pressing the enter key, which would be (manually) syncing to an external time source.

The problem doesn't change however.... in every case, regardless of how I load the DS1511, it's always 2-3 seconds behind what was loaded and transferred to the registers. I'll look at this a bit more, but perhaps I have a bad RTC... who knows. Maybe the built-in oscillator has an odd problem.

I've not had as much free time during the past month or so to work on this, but have made some additional progress. It's still learning and finding out some caveats on how the IDE controller works. Another issue that cropped up was having any sort of error on the IDE controller, e.g., requesting a block (LBA) that is out of range. It does generate an error, but no interrupt is generated by the IDE controller, so I had to re-code some of the BIOS routines to handle that.

I've also been working on a loadable utility that allows access to the DS1511 RTC and provides some functional tests of the Compact Flash IDE controller. It's currently just over 5KB in size, but there's a lot of message strings and almost NO optimization of the code. As it's a loadable utility, saving RAM space really isn't that important. I still need to finish up a couple more functions before a 1.00 version is completed, which might take some additional time yet.

I'm also about to order an updated set of PCBs for the RTC/IDE adapter which has some hardware changes and "should" work better. I did find a few issues with the Rev 1.00 board with certain power supplies. The new PCB should provide better noise immunity for the CF Card... time will tell. So, I'm attaching the latest BIOS and Monitor code that I'm currently using to develop the RTC/IDE Utility, which, so far, is working as intended.

I loaded the monitor code into the Kowalski editor/assembler and patched as necessary to get it to assemble (file attached). The assembler flagged the following line as an error:
Does that correctly assemble in the WDC assembler?

Also, some labels were flagged due to they starting with a numeral, e.g., 10MSCNT. I'm surprised the WDC assembler allows that, given that the MOS Technology assembly language standard requires that the first character of any label or symbol be alpha.

I also noted that you have both XMODEM and S-record loading functions, and in the comments, it says this is for loading from the console via a (presumably short) wire link. S-record makes sense in this context, since it is portable and has enough error checking to flag dubious records. XMODEM doesn't make sense in such a context, as the likelihood of a bit-level error in a short, hard-wired link is slim-to-none (I've never had it occur in loading my POC units with code, and that is at 115.2Kbps). Also, as a transfer protocol, XMODEM is slow and inefficient. You likely could eliminate the XMODEM code from your ROM and never miss it. Just an opinion.

You've got quite a few instances in which "magic" numbers are embedded in code. It would be better to define them via labels and use the labels as operands.

Speaking of assembling things, with Daryl's considerable improvements to the Kowalski simulator I have found no further use for the WDC package and have unloaded it from my workstation. If I were doing 6502 C development I'd keep it, but I'm not and the workstation on which I run the Kowalski package is an old Windows XP box with a small (36 GB SCSI) disk.

The integration of the assembler with the editor in the Kowalski package is very convenient—you can assemble your code from the editor and get immediate feedback about any errors. With the assembler now supporting the 65C816 in native mode, as well as implementing extended and long words, it's become a really good package for 6502 development. You should consider giving it a try.

Hi BDD,

Thanks for taking the time to examine my source files in such detail. In response to the following: Yes, this assembles fine with WDC Tools. I'm not sure why it wouldn't, as the # specifies decimal input (vs $ for Hexadecimal).

The Label 10MS_CNT also assembles correctly. Actually, I never thought about the label starting with a numeric versus an alpha character, so perhaps this would qualify as a "bug or feature".

As for the Xmodem code, my reason for using this is quite simple. I use a terminal application on OSX called "Serial" (with Windows I can use ExtraPutty). Both of these terminal applications support Xmodem-CRC for upload and download. As my C02 Pocket SBC has a single NXP UART for console (connected via a FTDI USB-UART module), I use the console port to also send and receive files to and from the SBC. This works perfectly fine... while not overly efficient, at 115.2K baud, it only takes seconds to load or save data. After all, I'm not transferring a huge amount of data either. I opted to add the S-record (S19 flavor) as I have that as the output file from WDC Tools and use it with my Dataman programmer for writing to the EEPROM.

My development setup is likely a bit odd. I use OSX as a core OS and use VMware Fusion to run other OSes, like WIndows, Linux, etc. I keep all of the data on the OSX side and share a directory to a Windows 7 VM, which is where WDC Tools runs. For an Editor I've been SlickEdit for many years, which I'm both familiar with and I like it. It was created by Clark Mauer, an old colleague that also wrote the internal E3 editor which has found it's way to the web over the years. I also have OSX setup for multiple screen sessions so I can simply slide between them with the mouse and have full screen views for the editor, Win7, Serial (usually 2 or 3 sessions), Acrobat for reference docs, Firefox for quick searches, lookups, etc.

For me, it just works... at some point I'll give the Kowalski tools a test run, but I'm used to formatting everything for use with WDC Tools and it's quick and simple for me at this point. Also, I've attached a ZIP file containing the LST file, as uploading them directly isn't supported.

Yup, I forgot you specify a decimal value with #, which is non-standard.
I have yet to run into an assembler that would permit a numeral as the first character in a label—I had no idea the WDC assembler allows such.

Well, I looked these things up in the Assembler-Linker guide.

1- The manual does state that Labels must start with either a letter or "_" or "~". Obviously this counts as either a bug or feature, depending on your point of view.

2- I looked up numeric entry... # is for immediate. Default numeric entry is decimal. I guess this can be considered a bug, but the assembler is ignoring the # for this statement.

I have opted to correct both of these in the source... so that should make it easier to move over to other assemblers should one care to. Good find on your side of course.