AVR Freaks

The XMODEM/CRC protocol is similar to the XMODEM protocol,
      except that the receiver specifies CRC-16 by sending C (Hex
      43) instead of NAK when requesting the FIRST packet.  A two
      byte CRC is sent in place of the one byte arithmetic checksum.

I'm going to take this to mean that ANYTIME it wants the first packet, even after a failure, it is to use the "C".

Here is what I am working on - a hexadecimal control panel Intel 8080 emulator.  The idea is for someone who has never used an "old" computer to be able to experience programming opcodes and stepping them one at a time, similar to some of the microprocessor trainers of the late 70's, but with more debugging faculties.  The user can view and change registers and set breakpoints for example.

I've tried to expose as many resources as I can from the ATMEGA1284 which has turned out to be quite decent.  The emulator will have 15K SRAM, 4K internal EEPROM,  96K FLASH mapped into the emulation's addressable area.  (The 96K FLASH is 3 bankable 32K sections at 0x8000-0xFFFF.).

There are 3 buttons that deal with all of the memory types in pages (256) and not bytes, so you can copy between any of the memory types, fill them with a value, or crc16 test them.  All have a page number, so you can copy from external EEPROM to SRAM, or SRAM to FLASH, or SRAM TO SRAM, and so on.  One of the page types is 601 (see table below) so you can copy to or from XMODEM to any memory type, or vice versa.  I don't need a filename or exact size to be sent, just the raw data in 256 byte pages (which in this case is two 128 byte XMODEM packets).

I might try to do Intel HEX format next at page 801/802 for COM1/COM2 which is really usart0/usart1.

I won't have compatibility with any specific trainer or old system, but I am going to get Altair 8K BASIC running on it by modifying its input/output routines.

AVR flash map (bytes not words):
  NAME			ADDR		SIZE
  application		0x00000		0x7700 (29.75K)
  configuration		0x07700		0x100 (256B)
  flash bank 0		0x07800		0x8000 (32K)
  flash bank 1		0x0F800		0x8000 (32K)
  flash bank 2		0x17800		0x8000 (32K)
  bootloader		0x1F800		0x800 (2K)

Emulated address map:
  NAME			ADDR		SIZE
  static ram		0x0000		0x3c00 (15K)
  internal eeprom	0x6000		0x1000 (4K)
  flash bank 0		0x8000*		0x8000 (32K)	*the flash bank switched in will be active
  flash bank 1		0x8000*		0x8000 (32K)
  flash bank 2		0x8000*		0x8000 (32K)

Copy Fill Test page map:
  NAME			PAGE		PAGES		GROUP
  static ram		0x00		0x3c (15K)	GROUP_SRAM
  internal eeprom	0x60		0x10 (4K)	GROUP_INTEEP
  flash bank 0		0x80		0x80 (32K)	GROUP_FLASH*	*the flash banks can be treated as contiguous together
  flash bank 1		0x100		0x80 (32K)	GROUP_FLASH*
  flash bank 2		0x180		0x80 (32K)	GROUP_FLASH*
  external eeprom 0	0x200		0x200 (128K)	GROUP_EXTEEP0
  external eeprom 1	0x400		0x200 (128K)	GROUP_EXTEEP1
  com1 xmodem		0x601		n/a		GROUP_COM1
  com2 xmodem		0x602		n/a		GROUP_COM2

>How about SD/MMC ? (possibly the closest thing to 5.25" / 8" disks that might typically have been used with an 8080/(Z80) based micro like this for program storage)

I keep wanting to do some more with SD/MMC, but this device is somewhat a "no filesystem" type device just dealing with memory ranges in pages/blocks.

>If you have a "disk" you can then look at running CP/M :-)

The idea has been wrestled, but it always comes down to simplicity and sram.  I thought about trying to do a custom CP/M version in flash leaving somewhere near 14K or so TPA, which is not enough already, but it probably is not worth the work.

>Anyway exactly what has specified:

>should exist?

Just firmware!  If you press the copy button above, it will prompt for the "copy page".  If you specify 601, then xmodem becomes a source so it will invoke xmodem download.  For the destination page then you could select a page for sram, internal eeprom, flash, or external eeprom and download directly to one of those memories.  Going the other direction, if you want to upload the entire 128K contents of an external exprom via xmodem, you would copy from page 0x200, destination page 0x601, number of pages 0x200.  Technically you could specify 601 for the "copy page" and 602 for the "destination page" and the device could be an xmodem router downloading pages from COM1 and uploading them to COM2 at the same time.  Not exactly useful, but I plan to test it just to see if it could work.  The idea behind this is having a single "copy" button that can be used to move memory from any memory to another memory, but in this case a virtual xmodem memory page is available that allows xmodem to be the source or destination or maybe both.