VIA address

Hello Nick, me again.

I notice in the "hardware.inc" file that your VIA is at address $7FF0-E. The Ben Eater board has its VIA at $6000-E.

It's not a problem, I can change the code to suit the hardware but I just wondered if I had missed another "hardware mod" that you have made? The $7FF0 implies your memory goes up to $6FFF and your IO is in the last 256 bytes (which is much nicer to my mind).

Adrian

Because of the way he did his address decoding $7FF0 onwards will work. The chip will respond to anything in the range $6000 to $7FFF and only uses the low-order 4 bits to actually work out which register is being addressed.

I changed it to that to allow for more memory or other peripherals - if you ever add them.

If you look at the truth table for CS1 and /CS2 on U5 (the VIA) you will see that the chip is selected if:

• A13 is high
• A14 is high
• A15 is low

Thus the chip is selected in the range $6000 to $7FFF.

Below $6000 A13 and A14 will not both be high, and at $8000 and above A15 will be high.

Ahh, yes, of course. Thanks.

Unfortunately, I have populated a second VIA, selected by A12 and a 65C51 selected by A9 so these will clash. I will change the code to suit.

I would love to get all the IO into 256 bytes to allow for that further expansion as you mention, but it's just a bit out of my capabilities yet. My head hurts when I try to work out the glue logic.

By the way, you have a link somewhere on your site to an article on the supercoders web site. Unfortunately the article is no longer live but I used the Wayback Machine to find it. Most interesting and impressive. I've been in the industry for nigh on 40 years and anyone who can write an assembler in machine code and a Pacal compiler in Assembler has my greatest respect.

Thank you. :)

Yes that article went down. I wasn't sure of the copyright implications of reposting it from the Wayback Machine, but I think I grabbed a copy.

...except

I mentioned above I have a 65C51 (selected by A10, not A9 as I said above) in addition to the 65C22. I was following Garth Wilson's 6502 primer ( http://wilsonminesco.com/6502primer/addr_decoding.html ).

Unfortunately this clashes with your extra memory mod. The 6551 stamps all over alternate 1kb chunks of the memory.

So. I need to come up with that glue logic to get all the IO in 0x7EFF-FFF.

A few AND gates should do it. You can manage without the extra memory, except my Adventure game needs it.

How about an 8-input NAND gate like the 74LS30 and then invert the output? Something like that should do it. Or the HCF4068B?

Ah you have the ACIA? I bought one but didn't use it in the end. The bit banging works OK, and after all the limiting factor is the ability of the processor to accept the incoming bytes in a timely way, so I didn't think the ACIA was bringing much to the table.

Well, yes, probably true about the ACIA but I wanted a retro computer to have all the retro stuff!

Anyway, I have (temporarily) removed it because I want to see Pascal working on this thing, so we are back exactly to Ben's board with your mods and your code is untouched.

I have the welcome banner up on the LCD and the serial monitor but have drawn a blank when typing anything in. I am on Windows and using puTTY which has never let me down yet. 4800N81 and local echo on.

I turned SERIAL_DEBUGGING on and put my 'scope on it. The debugging pulses out of PA2 are dead in the middle of the bits so I am a bit stumped really. I took a screenshot of the 'scope but this forum doesn't seem to allow attachment of images. I pressed "H" for help (and lots of other keys!) and could read the 0x48 on the scope (backwards, I think that is correct). I repeat for the carriage return key and can read the 0x0D too.

If I keep a key pressed for a long time so firing loads of typamatic characters at it I get is a very occasional garbled "Unknown command, type H for help.". So, SOMETHING is there and listening.

Any ideas of where I can look next?

EDIT: I think I found it. Your GET_LINE routine ignores CR and uses LF. PUTTY sends CR when enter is pressed. Maybe I can convince it to send LF instead (or as well).

I think you have it. I am used to Linux these days and lines are generally terminated with a LF, or indeed CR/LF from Windows, so it discards the CR and treats the LF as the end of the line.

CR only is kind-of weird. Like, from the old Apple world.

You can probably swap these around in the source, if you are recompiling anyway:



gpascal.asm at line 96-97.

Putty seems to have a configuration option: "Implicit LF in every CR" which might do it for you.

Configuration -> Terminal.

Hello Nick,
It was indeed the problem and it's working perfectly now. I can't tell you the simple pleasure it gives seeing a Pascal environment on a breadboard 6502.

puTTY's implicit CR with LF and implicit LF with CR don't seem to work. They appear to be to do with receiving rather than sending. I found a version of puTTY that someone has added an "Enter key gives CRLF" option and that fixed it.

Thanks again for your help.