You'd want to reverse the order of those steps. The MPU should be halted before it is told to tri-state the buses. Also, instead of tinkering with the clock, you could merely pull RDY low to stop the MPU. After the AVR has loaded the BIOS into RAM, you'd bring BE high and then bring RDY high. Since reset was asserted earlier the MPU will restart on the next rise of Ø2.


What about the A16-A23 lines? The MPU will not be driving any address bits as long as BE is low. If you are loading bank $00 you need to make sure that the RAM is not seeing any address greater than $00FFFF.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Another option is Michaels blind-load or the initial machine load I use (see ROMulus project http://forum.6502.org/viewtopic.php?f=4&t=3458). That is you control RESET and PHI2 with a microcontroller and manually step through the reset sequence and feed the W65C816 with the appropriate information at the given cycle. In my case the microcontroller also provides a mode switch signal that feeds into the address decoder to switch between the memory mapping in normal mode and during the blind-load. In blind-load mode all reads go to a tri-state buffer to read the byte from the microcontroller and writes go to the RAM. During this time the ROM region of the RAM will be write enabled by the address decoder. Once the ROM image has been loaded into the RAM the microcontroller switches the signal to normal mode and resets the CPU which then executes the normal ROM. The same signal that controls the address decoder could also control the source of PHI2. Or in your case, when you use a 74AC74 to generate PHI1 and PHI2 you could disable the CLK input of the FF (using a gate) when in blind-load mode and control the states of PHI1/PHI2 using the preset and reset inputs. As long as you switch the mode signal only with reset asserted the glitches in PHI2 during mode switch are not important. Thus you only need a microcontroller with very few signals. A

8 bits that go to the input of the byte buffer
1 mode switch signal
1 reset
1 preset 74AC74
1 reset 74AC74

so only 12 pins needed. I currently use a ATmega1248P in my ROMulus project and in other projects a ATmega328P (no its not an ARDUINO but that would do the job as well) and the ROM image is stored in FLASH. Currently I don't use a 74AC74 but create PHI2 via the ATmega using timer 2. The ATmega uses a 22.1184MHz buad-rate quartz and the fastest clock I can generate is 11.0592MHz. The Code of the AVR also includes a XModem (using a baud-rate clock allows stable 115200 baud upload speed) to upload to load any image from the PC into the RAM/ROM. The code also has a startup option that loads a image in FLASH and sets the clock on power-up.

A smaller AVR could be used and by replacing the tri-state byte buffer with a 74HC595 you can even save more pins, but the size of flash on a ATtiny gives room only for small ROMs. The good thing is that you only have an additional load on the data bus and not on any other time critical signals and the wiring effort is minimal.

How do you get the bios image file into the flash memory of the AVR? EEPROM is easily doable of course, but I'd have thought that you'd have to somehow glue the bios file to your code and then upload. Would you then try a direct byte-by-byte read of the flash memory?

I'm guessing it's simply included as constant data in the AVR code.

char foo[] = "\xaa\x55"; etc

Code generated with perl, sed, or your choice of tool, with the 6502 object file being the source data.

_________________
8 bit fun and games: https://www.aslak.net/

I assemble the image on my MAC using 64tass and then convert the binary into a include file for the AVR assembler, here is an example

I also have inlcuded a XMODEM function that blind-loads the image received via XMODEM. And you can not only download ROM images with blind-load, I also use it to download programs into RAM.
You should also have a look at 8bits 6502 Emulator http://sbc.rictor.org/avr65c02.html using a single ATmega1284P, his XMODEM routine updates the FLASH of the AVR directly.
So in other words, you are not limited to the size of the EEPROM, you can use all the unused FLASH binary storage for ROM Images. Even with all the functions implemented in the ATmega328P (PS/2 interface, control monitor, XMODEM, blind-load etc.) I have ROM for two 12kbyte 6502 ROM Images.

Not sure why it would be necessary to use XMODEM to transfer data across a hardwired connection. XMODEM was developed for use with modems operating through the PSTN, which has some inherent degree of data unreliability (a lot of unreliability back when Ward Christensen wrote XMODEM). Data errors on a properly configured hardwired TIA-232 link are extremely unlikely to occur—even at high data rates, greatly limiting the need for formal error checking.

Also, unless using XMODEM-CRC, the error checking is weak and easily fooled by single bit swaps in a packet.

I transfer code and data over to POC using nothing more than Motorola S-records. I've been doing this at 115.2Kbps for a long time and have only had one load abort due to an error, which error was due to a structural problem in an S-record, not hardware.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Why use XMODEM, now that's very clear, there are several reasons to use it on a hardwire connection. As a transmission protocol to send data from your PC/Mac to a SBC there are many advantages

As the protocol is very simple the footprint is very small in AVR assembler and in 6502 assembler code

It requires only a simple ACIA/USART with only RX and TX

It is available in almost all terminal emulation programs

You can use any serial port

You can transmit binary files, aka ROM images

I don't know of any other method that is as simple as Xmodem to connect a PC/MAC with a SBC. And as AVR can write their own flash you don't even require a programmer once you have flashed the code to the AVR. And of course I use CRC (see discussion of serial and table driven CRC calculation)

All good arguments. However, S-records are even simpler (mo CRC calculations required) and don't require use of a terminal emulator, as the format was specifically designed by Motorola for file transfers through hardwired connections. Also, no special protocol is required, no ACK/NAK, or similar. It's a constant data stream that works between any two entities, no matter the operating environments.

I use the S-record output from the Kowalski assembler, which happens to run on Windows. Kowalski's S-record output isn't a full implementation, as it doesn't generate S0 or S5 records, but in practice, that's not a liability. The physical hardware connection to POC is through a UNIX box (which used to be my 6502 development environment), but the Windows junk runs on top of Samba on a Linux box.

In order to get the data stream over from Kowalski to POC, I save the S-record object output into a file that is constantly monitored on the Linux box—this is one of several output formats supported by Kowalski. When the script that is doing the S-record file watching sees the timestamp change to a more recent date and time, a TCP connection on a dynamic port is made via netcat to the UNIX box, which also has netcat running as a listener. Once the connection goes live the S-record file is catted to netcat's stdin, which then passes it via the network to netcat on the UNIX box, whose stdout is directed to the appropriate serial port. From there, the data flow is to POC via the unit's auxiliary TIA-232 port. POC has an S-record loader built into the firmware to process the incoming data. As each S-record has a checksum field, error checking is inherent in the decoding process. However, I've never had a transmission error occur in some six years of using this process.

When I was initially designing POC and was working out how to transfer code to it from the assembler, I looked at several methods, XMODEM-CRC being one of them. I came to my senses when I realized that no elaborate error checking or transmission protocol was necessary on a short-range serial link, especially one using hardware handshaking.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I use S-records, but it's always a bit of a pain to do the conversion on the host side - I have to find some notes on how to use srec_cat. The great advantage is that the loader is trivial. If I had an XMODEM loader, it being available implicitly on the host side would be a great advantage.

Yep, S-records are nice but its always a problem to create them, thats why I don't use them. 64tass only creates binary files.

Similar to S-records, I use Intel Hex for transferring machine-language files to the workbench computer. Almost the only thing I use it for is to send the data for programming PIC microcontrollers. I don't send an actual file, only the text content of the file, over RS-232 (the PC thinks it's just sending it to a serial line printer), and the last line of the Intel hex is ":00000001FF" which tells that it's done. Like BDD, I have never had an error in it.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

My assembler supports binary, hex, S19, S28 and S37 (S1/2/3 with S5 and S9 records, no S0 as it contains no useful information).

I have had trouble sending S-records to SBCs over connections with no flow control and polled I/O that is why the SXB-Hacker has XMODEM download. (The SXB hacker lets you page out the WDC firmware ROM so you can't have interrupt activity as the new ROM image is being loaded)

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Back in the day, the S0 record was used to convey the filename to the target machine. I have processing support for S0 in POC's firmware but not having an actual filesystem on the disk, wouldn't be able to do anything with the information.


Some type of flow control is usually necessary due to processing lags at the receiving end. Absent hardware handshaking, you could do XON/XOFF, which is generally reliable to 9600bps on a clean line.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

My 65C02 system has a single serial port which I use as a console via a terminal program. I use either ExtraPutty or Teraterm, both of which support Xmodem-CRC for transfer. To be able to transfer data over to my board, I implemented Xmodem-CRC through the console port. It does the CRC checking as well and has worked without issue for quite some time (only tested with ExtraPutty and Teraterm). I recently added S-record support to my Xmodem code to automatically detect S19 records (as formatted by the WDC Tools package) so I can write code and download it to the board. The (Xmodem) loader allows for an optional load address for data download, which is used as an address offset for S19 records.

Needless to say, some other folks have more graceful methods and dedicated ports to do their (data) transfers with, but so far my implementation has worked well and I've been doing more testing with writing code, transferring it to the board and moving it to the EEPROM for execution. The only down side is that it takes 690 bytes of ROM space between code and text messages. I'm hoping to cut that down a bit, once I have some free time to go back and look it over again.

_________________
Regards, KM
https://github.com/floobydust