Hi all,
I'm working on Jarod's Atom, fitting a RAMROM board and AtoMMC.
With the RAMROM fitted, and a tested at 2MHz CPU the machine would not run at 1.7MHz, it would just hang, but was perfectly OK at 1MHz, so I knew the RAMROM board itself was working. After a check that I had connected the required patch wires correctly and a poke with the scope I rew a blank.
But then I found that some of the modern software on the software archive required a 6522 fitted (for timers).
Now once I connected the 6522, the 1.7MHz mode miraculously started working, this seems most odd I guess it could be that the 6522's affect on the lines it's connected to improve the signals to the point that it all hangs together.
Thoughts anyone?
Cheers.
Phill.
Now this is Weird.
Re: Now this is Weird.
IIRC, we had a similar issue with my Issue 4 Atom when you fitted the RAMROM board for me in Leciester, which must have been about 5 years ago now. The machine worked fine at 1Mhz but not at 1.7Mhz. A while later I bought the Atom along to an Atom meetup in the Netherlands. Roland made some small adjustment to the Atom for me (don't remember what) and while we had the case open he noticed it didn't have a 6522, so he installed one. I then mentioned the weird thing about it not working at 1.7Mhz so we tried it and, to my surprise, it worked fine. I then promptly forgot all about this until reading your post this afternoon.
Re: Now this is Weird.
I think it's because the Atom MOS relies on R39/40/41 to pull down data bus bits D1/2/3 when the 6522 is missing, so that the BEQ at FF0D is taken:
The pulldowns work reliably at 1MHz, but there isn't sufficient time at 1.7MHz for them to act.
The MOS thinks the printer is enabled, then gets stuck forever waiting for it to become none-BUSY.
At least, that's what I think might be going on.....
You can confirm this by looking at the address bus. It will be in a tight loop here:
Dave
Code: Select all
FF08 AD 0C B8 LDA #B80C Get the VIAs peripheral control register
FF0B 29 0E AND @#E Is it set up, ie <STX>ed ?
FF0D F0 27 BEQ #FF36 ..no, can't send character - return
FF0F 68 PLA Restore character to be sent
WAIT FOR PRINTER NOT BUSY
The MOS thinks the printer is enabled, then gets stuck forever waiting for it to become none-BUSY.
At least, that's what I think might be going on.....
You can confirm this by looking at the address bus. It will be in a tight loop here:
Code: Select all
FF10 2C 01 B8 BIT #B801 Busy ?
FF13 30 FB BMI #FF10 ..yes, wait for printer to be not busy