MOVE command success and a bug

just finished testing the MOVE command for the 8-bit project, which copies a block of memory from one location to another, and takes the form

MOVE S$xxxx,D$yyyy,L$zzzz

where S is the Source address, D is the destination address, and L is the length of the block to copy.  as usual the addresses and length must each be exactly 4 hex characters long.  note that the S/D/L characters are, strictly speaking, optional.  i locate hex arguments by searching only for the $ and then looking at the next four characters.  i know this is a bit of a shortcut, but it works for now.  if/when everything is working, i can go back and be more strict about such things.

memory is copied in full 256-byte pages, plus a final partial page if needed.  full pages are copied top to bottom, i.e. starting at offset 0x00 and going to 0xFF.  the partial page, by contrast, is copied bottom to top, i.e. starting at offset 0xzz and going to 0x00.  i did this because it allows me to use the LSB of the stored length parameter as both the counter and the offset index for the LDA/STA commands.

note that their is no argument checking done – so if xxxx < yyyy < xxxx + zzzz, part of the memory to be copied will be overwritten, possibly before it has been copied.  this would obviously lead to unexpected results, and should be avoided.  at some point in the future i hope to improve this function to detect such cases and change the order of the move to produce the intended results.

so, about that bug…as i was debugging MOVE, i found a bug in SHOW (which i was using to verify whether MOVE was working correctly).  The bug was that SHOW would not allow a hex character ‘F’ in its address argument. however, the actual error traced back to the function that converts command line arguments into hex values, meaning that, in reality, NO function would allow an ‘F’ in their arguments.

the cause of the bug is that, in trying to determine if the character i had pulled from the input buffer was a legal hex character, i was doing a CMP #0x0F; BPL err.  however, zero is considered to be positive, so an ‘F’ would cause a branch to an error condition.  but because i was never setting an error code, no error message was generated – it just returned to the input prompt.

the fix was simple – change the CMP #0x0F to CMP 0x10, so that an ‘F’ now goes to -1 and the BPL branches properly.


change of direction

so i had said the next step in the 8-bit project was to start hooking up the hardware to bypass the apple SSC and move the serial port function into my own hardware.

then i looked at my bank account, and realized that i can’t afford to be spending any money on hobbies right now.  so since i don’t have all of the chips i need to implement the serial port hardware on hand, i’m instead going to focus on the firmware and filling out whatever functions i can without needing to change the hardware any…

XMIT command success

i’ve been on vacation and busy with some other things, so i didn’t have a chance to work on the 8-bit project for a couple of weeks.  but the last two weekends i’ve been working on the XMIT command, and finally finished it up.  as usual, there were a couple of stupid little bugs in the assembler that i didn’t catch.  one was properly loading up the X register with the number of full pages to transmit, and the other was not having copied the data location information into the alternate location for use as a counter.

coding XMIT actually wasn’t all that difficult – i just started by copying the code for RECV and switching the sense from receiving to transmitting.  i also needed to update my PC-side utility to allow it to receive as well as transmit data.

the form of the command is

XMIT a$xxxx,l$yyyy

where ‘a$’ and ‘l$’ represent the starting address and length of the data to be sent, respectively.  both arguments are required, and the order must be as shown – because i’m taking a shortcut and ignoring the letters and assuming that the arguments are in this order.  i also skip the $s and assume that the value is in hex – decimal simply isn’t allowed.  i justify this because a) it works and b) i do intend, if i ever manage to complete this project and get it running on my own hardware design, to at that point go back and flesh out the firmware to provide a better user experience.

the format of the transmitted data is identical to that for the RECV command.

with XMIT and RECV now both working, i think the next step is to go back to the hardware side and integrate the serial hardware onto my breadboard, bypassing the SSC.

SHOW command finalized; next steps

just did the final testing on the SHOW command – having it print out the next 8 bytes if a blank line is entered and SHOW was the most recent command.  again, my goal here was to emulate how the apple monitor works, allowing the user to see successive 8-byte chunks without having to enter any additional keystrokes beyond the ‘return’.

next, i’m trying to choose between implementing the XMIT command (transmit data over the serial port) or the SET command (set memory contents).  i don’t have a strong preference for either right now, though i think XMIT makes sense because that should also spur me to work on integrating my own serial port hardware onto the breadboard, which is the last apple-based hardware that i need to get working before i can move off to my own full hardware.

that also brings up the matter that i need to get to work on designing the full hardware schematic, then laying out the pcb(s), getting those manufactured, etc.  so hopefully i’ll be posting something soon on my thoughts on that…

SHOW command success

another day, another success 8)

yesterday i successfully tested the SHOW command for the 8-bit project, which shows the contents of memory, and takes the form

SHOW [A$xxxx]

where as usual square brackets indicate that the address parameter is optional, and (if present) the address must be 4 hex characters long.  if the address parameter is omitted, then output begins from the byte after the last byte show by the last SHOW command.

format of the output is

xxxx:yy yy yy yy yy yy yy yy

where ‘xxxx’ is the address of the first byte.  up to 8 bytes are shown; the loop exits when the address of the next byte to be shown is an exact multiple of 8.  this makes understanding the data a little easier, since each (sans argument) SHOW after the first will always show 8 bytes and start at either xxx0 or xxx8.  you might recognize that this is very similar to how the apple monitor works when displaying data, and that was in fact my model.

there is one more functionality to be written and tested for SHOW, and that is the ability for the system to remember the last command entered, and then if the user hits ‘enter’ on an empty line and the last command was SHOW, to respond as if the user had entered SHOW without an argument.  this will better match the apple case, where continually hitting ‘enter’ will display the next 8 bytes, allowing the user to display regions of memory 8 bytes at a time without having to type SHOW each time.

i’m not sure where i’ll go next…i need to start designing and building the real hardware at some point, and i’m just about at the point where i have the software ready for that.  on the other hand, the serial port code currently uses the super serial card, which obviously won’t be available in my design (although i will be using a 6551 chip pulled from an SSC).  so it would be good to get that set up on the breadboard, update the code, and test it before moving to final hardware.

RECV command success

today marked the successful testing of the RECV (serial receive) command for the 8-bit project.  the format of the command is
RECV [A$xxxx]
with the square brackets indicating that the address argument is optional.

this isn’t the first command that’s been tested, but it is the first since i’ve started this blog, so it gains the distinction of the first success that i report here.  i do intend to go back and cover the already-tested commands as well though.  also, there will be an overview post going over the entire command set as currently planned.

the serial data is received in the following format:

  1. the 2-byte address at which the data should be stored (if the address argument is included, the received address is replaced by the argument), LSB first.
  2. the 2-byte length of the data to be received, LSB first.
  3. the data itself, in 256-byte blocks.  before each block, an ACK (0xAA) is sent to inform the sender that the software is ready to receive.  after receipt of the last block (which may be less than 256 bytes) a final ACK is sent to inform the sender that receipt is complete.

the address argument must be exactly four hex characters long.  so e.g. if you wanted to receive the data at decimal address 768, you would need to enter the address argument as A$0300; A$300 would be rejected as an error.  while not perfectly ideal, i’m concentrating at this point on getting everything to just work.  assuming i ever get to the point of completing this project to the point where it’s fully working on native hardware, then i may go back and add ‘niceties’ such as allowing a 3-character hex address to be interpreted properly.

to keep the user updated on the progress of the transfer, the command outputs several pieces of information:

  • the command starts by outputting an ‘I’ to indicate it has initialized and is ready to begin receiving data
  • after receipt of the address and length arguments, an ‘R’ is output
  • after receipt of each 256-byte block (and the last less-than-256 byte block if needed), an additional ‘R’ is output
  • after data receipt is complete, a status message is output on a new line: “File received at $xxxx:yyyy bytes”, where xxxx is the address the data was stored at and yyyy is the length of the data received.  both are in hex, and both are exactly 4 hex characters long.

testing was performed both with and without the address argument, as well as with an invalid address argument to ensure the testing of that code.

the next command to be worked on is SHOW, for displaying the contents of memory.  in fact, after completing testing of RECV this morning, i wrote the code for SHOW and am ready to upload and test that.  i may do that tomorrow…

parallels vs boot camp

so i think i’ve finally finished setting up my macbook and am ready to take the G5 and my netbook offline as primary computers after making sure i’ve got all the data off of them that i need.  the last part of the puzzle was parallels, which if you’re not familiar, is a program that allows you to run windows from an intel-based mac.

i had first installed windows using boot camp, but parallels doesn’t like that.  i believe the issue is that parallels wants to install it’s own set of virtual hardware, but boot camp has already been set up to recognize the physical hardware.  so when presented with a completely different set of hardware the first time you attempt to start windows using parallels, windows gets confused and blue screens.  that then confuses parallels, which goes into a boot-loop until you tell it to stop.

luckily i hadn’t installed a whole lot of stuff in boot camp, so i didn’t really have a problem with deleting that partition and using parallels to build a virtual windows install.  however, if you’re well-invested in a boot camp partition, you should definitely take advantage of the 14-day free trial for parallels to find out if you can get it to work properly.  anyway, i now have all the major things that i need to have working in windows, working.  that list includes

  • microsoft onenote – this simply isn’t available for the mac at all.  i’ve used it for a half-dozen years now, and i really like it.  i’ve tried mac-native programs that claim to be equivalents, and a couple of them were ok.  the big problem was that none of them could import my existing onenote files, so that’s a deal-breaker.
  • crimson editor – this is a really nice programmer’s editor that i found.  my selling point on it was the ability to create my own syntax-highlighting rules, which i needed to do for 65C02 assembly language for my 8-bit project.  unfortunately, it’s windows only.  it’s also no longer being actively developed; the successor, emerald editor, is available for mac, but (a) it appears to have been effectively abandoned at this point as well, and (b) the currently available version doesn’t really have all the functionality i need.
  • HXA (hobby cross assembler) – i use this for assembling the code for the 8-bit project.  the source is available, but it’s in a proprietary variant of awk that isn’t available on mac.
  • visual c# 2008 – when i need a small utility for something, i’ll whip something up with this.  i’ve installed mono on the mac side, but haven’t tested it out yet, so i want to have this available if i need it.
  • usb-to-serial cable – for transferring the 8-bit software over to the apple.

i also have a number of older games that are windows-only that i’ll eventually put into parallels so i can play them again.  i wasn’t able to play most of them on the netbook because it had a 1024×600 screen and the games required minimum 1024×78.

for the programs mentioned above, i run parallels in what they call ‘coherence mode’, which means that the windows program windows coexist with the mac windows on a single desktop, show up in the dock, etc.  they still look like windows, but they’re integrated into the mac desktop, like so:

i like the integration and not having to switch back and forth with the virtual machine.  my mac home directory documents folder even shows up as ‘my documents’ on the windows side, so there’s seamless data sharing.

ok, enough of a commercial for parallels…time to get back to some useful work.