G-Pascal compiler and on-board assembler for Ben Eater's PC

[Nick Gammon]

Hello everyone!

I see I got a mention on this forum in 2010: viewtopic.php?t=2073

I made a "tiny" Pascal compiler in 1979 for a 6800 evaluation kit board. This compiler resided in UV-EPROM on the board itself.

In 1982 I ported it to the Apple II, calling it G-Pascal, and in 1983 to the Commodore 64. Those versions had to be loaded from disk, naturally.

It has lain dormant for a few decades now, however after buying Ben Eater's 6502 breadboard computer kit last Christmas (ie. December 2021) I thought it might be time to revive it, and go back to a Pascal compiler resident in EEPROM.

Fortunately I still had a listing of the Commodore 64 version, and managed to get it to assemble using vasm. Then the hard work came of removing all the stuff about the Commodore 64, and working out what the heck I was thinking when I wrote it 40 years ago.

The Pascal stuff only took about 16k out of the 32k EEPROM, so I added an on-board assembler as well.

Still with room to spare I added SPI and I2C support, CRC calculations, and support for the LCD on Ben's board.

This is all available on GitHub: https://github.com/nickgammon/G-Pascal.

Documentation is part of the GitHub download, and also viewable here: http://www.gammon.com.au/G-Pascal/.

To "talk" to the board you use 4800 baud serial comms (if using a 1 MHz clock), connected to the 6522 chip on Ben's board using an FTDI cable.

You can watch it in operation on Vimeo: https://vimeo.com/682663375.

There are also some demonstration videos there of the I2C and SPI interface.

You are welcome to use it "as is" or extract any functions you find useful, such as the I2C routines.

Having an on-board assembler is handy because you can code, assemble and test without having to remove EEPROM chips or muck around with external programmers. I developed the I2C and SPI routines using the on-board assembler.

- Nick

[BigEd]

That's wonderful Nick, great stuff - welcome here, and thanks for sharing, documenting and demonstrating your offering! (And thanks too for open sourcing it.)

It is indeed handy - more than handy - to have an assembler as well as a high level language.

[plasmo]

Nick,
Great project, I like it a lot. I like the way you use wirewrap wires and headers to connect IC's. These are solid connections with test points readily available.

I'm unfamiliar with Ben Eater's hardware but like to port your software and Ben Eater's hardware to my CPLD+6502 trainer. All I see on Ben Eater's hardware is a 65C22 so my question is how to communicate via serial port to Ben Eater's hardware?
Bill

[Nick Gammon]

I have documentation about that here: http://www.gammon.com.au/G-Pascal/hardware_mods.htm.

I use two ports on the 65C22 for transmit and receive data, and CB2 for detecting a falling edge on receive data (ie. the start bit) and producing an interrupt. The serial comms is bit-banged and seems quite reliable now I got the timings right. You could conceivably use an ACIA chip (and I have a few here to test with) but I doubt you could get the speed any higher anyway because you still need the main processor to keep up with it.

If you put in a 4 MHz oscillator, as I have done, the speed goes up to 19200 baud which is quite acceptable for loading and saving code.

If your hardware doesn't have a 6522 then you could just rewrite two functions: one that receives an incoming byte and one that sends a byte over serial.

In my case I use an edge interrupt on the start bit and then a timed loop for incoming serial data. For sending I set up the 6522 to generate an interrupt for each outgoing bit using its timer functionality (continuous interrupts on T1) and use those interrupts to clock out bits at the correct rate.

[plasmo]

Thanks for the modification page. I think I have enough information to port your design over. I’ll start with W65C22 at 4Mhz, then I’ll emulate 6522 function in CPLD so I should be able to run it to 12Mhz. 24Mhz operation will require more work.

I have done hybrid serial scheme where receiver is implemented in CPLD logic but transmitter is bit-banged. This save the precious CPLD logic yet enable high baud (115200) serial communication.
Bill

[BruceRMcF]

The W65C22 I see at Mouser is the 14MHz rated part.

[BruceRMcF]

The C64 source was at one time available. Is it still on hand? That would seem like a good starting point for a Vommander X16 port.

[drogon]

BruceRMcF wrote:

The C64 source was at one time available. Is it still on hand? That would seem like a good starting point for a Vommander X16 port.

The source to the current project is all there:

https://github.com/nickgammon/G-Pascal

I'm interested in porting it to my Ruby system if/when I get time...

-Gordon

[Nick Gammon]

BruceRMcF wrote:

The C64 source was at one time available. Is it still on hand? That would seem like a good starting point for a Vommander X16 port.

The C64 source is at http://www.gammon.com.au/GPascal/source/ however it is lightly documented as memory was at a premium when I wrote that. You are better off using the source on GitHub as that has more features and is much better documented.

To port it I suggest:

• Change these at the start of gpascal.asm to reflect where your RAM ends and where your ROM starts:
  

  Code: Select all

  START_OF_ROM = $8000     ; where the ROM chip starts
  HIGHEST_RAM  = $3FFF      ; original board hardware

• Change "USE_CP437_FONT = 1" to "USE_CP437_FONT = 0" to save 2k of the ROM.
• Possibly change, in interrupts.inc, from "here for a hardware IRQ" down to "irq_done" to handle your hardware interrupts the way you want to. (Leave the BRK stuff in if you want the breakpoints to still work).
• If your processor does not support the WDC65C02 instructions you may need to rewrite some stuff like TSB and TRB to do it the longer way.
• Have a look at what gets executed if "EMULATOR = 1" because that is how I interfaced with an emulator for development on my PC. In particular you need a "character out" and "character in" function for talking to and from the user. In the live version CHRIN and GETIN are the same code. For the emulator CHRIN was written to get a line of text from the user and drip-feed a character at a time when it was called, getting a new line when the first line was exhausted. In the live version buffering user input is done on the board.
• You may want to modify what "hardware_init" does.

[drogon]

Nick Gammon wrote:

BruceRMcF wrote:

The C64 source was at one time available. Is it still on hand? That would seem like a good starting point for a Vommander X16 port.

The C64 source is at http://www.gammon.com.au/GPascal/source/ however it is lightly documented as memory was at a premium when I wrote that. You are better off using the source on GitHub as that has more features and is much better documented.

To port it I suggest:

• Change these at the start of gpascal.asm to reflect where your RAM ends and where your ROM starts:
  

  Code: Select all

  START_OF_ROM = $8000     ; where the ROM chip starts
  HIGHEST_RAM  = $3FFF      ; original board hardware

• Change "USE_CP437_FONT = 1" to "USE_CP437_FONT = 0" to save 2k of the ROM.
• Possibly change, in interrupts.inc, from "here for a hardware IRQ" down to "irq_done" to handle your hardware interrupts the way you want to. (Leave the BRK stuff in if you want the breakpoints to still work).
• If your processor does not support the WDC65C02 instructions you may need to rewrite some stuff like TSB and TRB to do it the longer way.
• Have a look at what gets executed if "EMULATOR = 1" because that is how I interfaced with an emulator for development on my PC. In particular you need a "character out" and "character in" function for talking to and from the user. In the live version CHRIN and GETIN are the same code. For the emulator CHRIN was written to get a line of text from the user and drip-feed a character at a time when it was called, getting a new line when the first line was exhausted. In the live version buffering user input is done on the board.
• You may want to modify what "hardware_init" does.

Thanks for the pointers. If it fits inside 16KB then it ought to be relatively easy to port it to my Ruby 6502 and BBC Micro.

-Gordon

[Nick Gammon]

I have been making some enhancements to the "shell" since the initial release. In particular:

• You can write to memory locations from the shell, for tweaking stuff
• You can resume after a breakpoint, to continue executing once you have inspected registers, memory etc.
• You can manually JMP or JSR to any memory location
• You can list all of the inbuilt (library) symbols

[Nick Gammon]

drogon wrote:

Thanks for the pointers. If it fits inside 16KB then it ought to be relatively easy to port it to my Ruby 6502 and BBC Micro.
-Gordon

Well, it doesn't. :)

Since I had a 32KB EEPROM I went a bit hog-wild adding extra features, like the assembler, CRC calculations (themselves not very large), I2C support, SPI support, a CP437 font bit image, and fancier editor features. Currently it takes over 23KB. A quick check of sizes from the listing gives these rough sizes:

• Assembler: 4.6k
• Pascal compiler: 3.5k
• Pascal runtime: 2.2k
• CP437 font: 2k
• Editor: 3.8k
• Support routines, hardware interface, arithmetic, etc.: the rest

You can probably fit it into 16k if you omit the font stuff (not in itself particularly important, and there is already a conditional symbol to do that), and either the Pascal stuff or the assembler. It depends what you want to do with it.

I can probably add conditional compiles to make that just a case of changing one or two symbols, if that would help.

[BruceRMcF]

Nick Gammon wrote:

BruceRMcF wrote:

The C64 source was at one time available. Is it still on hand? That would seem like a good starting point for a Vommander X16 port.

The C64 source is at http://www.gammon.com.au/GPascal/source/ however it is lightly documented as memory was at a premium when I wrote that. You are better off using the source on GitHub as that has more features and is much better documented.

Thanks! I had tried that address, but it was on my phone browser and didn't work ... now that I am home, I found that it works on my laptop, so I've downloaded the sources. I'll also have a look at the current project code, and see which one looks to be a shorter jump for me.

In any event, it would likely be primarily based on one with code borrowed from the other, since the target would be to run out of the 8KB High RAM window, so whether it is 2 or 3 High RAM segments is not so critical.

[Nick Gammon]

To fit into 16k of ROM you can omit either the assembler or the Pascal compiler. Also omit the CP437 font and the LCD support.

The directives to do that are near the start of gpascal.asm:

Code: Select all

LCD_SUPPORT = 0       ; 1 = support LCD, 0 = not. Unset if you have removed the LCD.
USE_CP437_FONT = 0    ; 1 = include the symbols for the CP437 font for use with MAX7219 chip, 0 = omit them
USE_PASCAL = 0        ; 1 = include the G-Pascal compiler, 0 = omit it
USE_ASSEMBLER = 1     ; 1 = include the assembler, 0 = omit it

In the above configuration, it uses 15267 bytes of EEPROM.

---

Code: Select all

LCD_SUPPORT = 0       ; 1 = support LCD, 0 = not. Unset if you have removed the LCD.
USE_CP437_FONT = 0    ; 1 = include the symbols for the CP437 font for use with MAX7219 chip, 0 = omit them
USE_PASCAL = 1        ; 1 = include the G-Pascal compiler, 0 = omit it
USE_ASSEMBLER = 0     ; 1 = include the assembler, 0 = omit it

In the above configuration, it uses 16267 bytes of EEPROM - slightly short of 16k (16384 bytes).


I have added some notes about that to http://gammon.com.au/G-Pascal/installation.htm

[HansO]

Nice to see Pascal on a 6502 in action again after so many years!

How difficult would it to port to a 6502 machine like (an expanded) KIM-1 clone with a 65C02?
- That means replacing character I/O routines, which would be not too difficult, hardware.inc has to be rewritten of course
- The RAM memory map of the expanded KIM-1 (and clones like MicroKIM, Corsham KIM clone, PAL-1) is not very standard:

$0000-$1400 RAM (zeropage, stack, free above $0200)
I/O, KIM-1 ROMs in between

$2000- RAM (32K often)

$0200 is used for work buffer, OK.

Start of RAM is that easy to adapt? I see TEXT_START with comment currently $0300, is that enough to change?

Hans