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

[BruceRMcF]

Aha, I was assuming VIA running at master clock for stable timing. 16MHz is still a good speed.

[BruceRMcF]

plasmo wrote:

...
My conclusion is the VIA can not be overclocked above 18MHz but if the VIA functions are replaced by CPLD, 24MHz operation is still possible so the notion of copying flash into RAM and operating in RAM is still viable. Executing in RAM has the advantage of uploading new software to test it out before burning into flash.
Bill

16MHz would do me. I am intrigued by the idea of flipping the sizes in the 16/16/32 memory map to 32/16/16, using NAND(A15,A14) for the /ROM_CS, and banking the ROM with a VIA pin (eg, PB4), with I/O device /CS from: /IO_CS=NAND[A15,NAND(A14,A14)].

Then to get fancier in the $8000-$BFFF part of the memory map, a 3 to 8 active low decoder/demux (eg a 74xx156), to pick $A13-$A15 as %101 to a new select for $A000-$BFFF and narrow /CS_IO to $8000-$9FFF with the %100 decoded line - and the /CS_IO logic goes from two layer of logic to a single layer. Something like:

• /ROM_CS = /ROM_OE = NAND(A15,A14)
• ROM_A14 = VIA1_PB5
• /RAM1_CS = NAND(PHI2,NAND(A15,A15))
• /RAM1_OE = A15
• DECODE_G1 = DECODE_G2 = NAND(PHI2,PHI2)
• DECODE_C1 = DECODE_C2 = A15
• DECODE_A = A14
• DECODE_B = A13
• /IO_CS = DECODE_1Y0
• /RAM2_CS = /RAM2_OE = DECODE1Y2
• RAM2_A14 = VIA1_PB4
• RAM2_A13 = VIA1_PB3
• VIA1_C0 = A12
• VIA2_C0 = A11

[BigDumbDinosaur]

Nick Gammon wrote:

I got my breadboard system to run at 5 MHz but not 8 MHz. I strongly suspect the speed of the EEPROM is the limiting factor there.

EEPROMs are pretty slow, which is why I haven't used one in my designs. I've got a bunch of AMD 55ns EPROMS which will tolerate 12.5 MHz without wait-stating.

[okwatts]

Hi Nick
Thank you for making this available. I was able to get this going on Rich Cini's SBC2.7 both using the VIA and adaptation to use the ACIA (different EEPROMs). My major issue initially was ensuring I had the jumpers in to enable interrupts on the VIA (took longer than it should have to dawn on me). I could see the welcome message, noted that it needed to change lf to crlf on output but got no input response until I did lf instead of cr. I am using picocom on linux so it was easy to setup an input and output mapping for those changes. I have been happily exploring both the assembler and the Pascal using the supplied demo programs. I have noted that I get spurious characters added in the editor when I have done replacement commands, so I'm not sure what is happening to cause those. I have one example to share if you would like to verify this. It is surmountable by adding a new line to replace the one with the bad character and deleting the offending line. So far it has been a pleasure to have this in the arsenal of programming tools, more exploration to come.
PS I have been using a 4 MHz crystal and have not tried higher.

[Nick Gammon]

I would certainly appreciate it if you can send a reproducible example of the find/replace not working. There may be an edge case I missed (like the start of the line, the end of the line, that sort of thing).

As for the newlines, you could change the symbol NL in gpascal.asm to be $0D rather than $0A and then it should treat carriage-returns as a line terminator. You would also need to find the two places where it looks for an incoming $0D and discards it. Look for references to #CR. Or maybe swap them so that it would go from (existing):

Code: Select all

NL               =  $0A   ; newline
CR               =  $0D   ; carriage-return

to:

Code: Select all

NL               =  $0D   ; carriage-return
CR               =  $0A   ; newline

That should effectively reverse the meanings of those two line terminators.

[Nick Gammon]

By the way, the latest release fixes what I regard as a bug. Labels (in the assembler) start in column 1, right? So a word in column 1 is added to the symbol table, regardless of what follows it.

Now consider this case:

Code: Select all

 lda #1
clc
 adc #2

The "clc" in the example above is in column 1 and thus is a label and not an opcode. This could easily be overlooked if you are browsing code, and would be an easy mistake to make when typing. My earlier versions accepted valid opcodes as labels, so the only time you would realise that the "clc" was not assembled into the output was if you happened to do it twice (and then get a duplicate label error).

Version 4.07 onwards rejects valid opcodes as suitable labels.

Interestingly, vasm does not. See here:

Code: Select all

                        	   220: START    =  *
00:DC80 D8              	   221:   cld             ; cancel decimal mode
                        	   222: clc
00:DC81 78              	   223:   sei             ; no interrupts yet

The CLC on line 222 does not generate any code. If you happen to do that again you get an error:

Code: Select all

                        	   220: START    =  *
00:DC80 D8              	   221:   cld             ; cancel decimal mode
                        	   222: clc
                        	   223: clc
                        	     ^-ERROR:0075
00:DC81 78              	   224:   sei             ; no interrupts yet

error 75 in line 223 of "gpascal.asm": label <clc> redefined

Maybe they are following some standard, but it seems an odd thing to permit.

[BillG]

A more foolproof solution is to require that all labels be terminated by a colon (:)

There is a limit to how many errors an assembler can/should be expected to detect.

Consider

Code: Select all

    lda     Label,X

vs

Code: Select all

    lda     Label ,X

Some assemblers interpret the ",X" in the second case as the start of a comment. The best solution to that one is to require all comments to start with a semicolon; the assembler can either ignore the space or flag the ",X" as extraneous.

Some errors cannot be reasonably detected:

Code: Select all

    lda     #Value

vs

Code: Select all

    lda     Value

[BigDumbDinosaur]

BillG wrote:

A more foolproof solution is to require that all labels be terminated by a colon (:)

I disagree.

Most assemblers in current use make terminating a label with a colon optional, if they allow a colon at all. Why force someone to accommodate yet another syntactical rule?

[BillG]

If the goal is for the assembler to detect programming errors, there has to be rules.

Requiring a colon on a label is no more or less arbitrary than disallowing the usage of clc as a label.

[Sheep64]

I apologize for my deadpan comedy. I thought that the regulars would be amused by describing GARTHWILSON's one post per day over 20 years as "occasionally" posting on the 6502 Forum. It honestly didn't occur to me that anyone would take it seriously. To avoid future incident, I have designed a label (which does not say WARNING: CONTAINS NUTS).

GARTHWILSON on Wed 23 Mar 2022 wrote:

this address decoding scheme is definitely not so absolutely brilliant that no one else could have come up with it.

Partly as an exercise, I spent eight days working on address decode schemes. The best I could devise was one 74x139 for 4*16KB segments and read/write qualification. I've seen both parts used separately but I'm not sure if they have ever been used together. One 74x139 is a little better than the never used five NAND gate arrangement, although the chip shortage may make that moot.

There is one part of the three NAND gate design which is copied without question since GARTHWILSON published it 22 years ago. The ganged inputs of the NAND gate used as a NOT gate create one unnecessary load. There are two other ways to implement this but the most conservative choice has been made for historical reasons. I estimate this slows the design by 300ps. I presume that the ganged input prevents "latch-up" and this is described in detail in Fairchild Application Note 363, Jun 1984. (The Fairchild Application Notes are fairly much like the old RFCs but for digital electronics.) Latch-up occurs when a voltage spike causes an inadvertent PNPN SCR to short to ground. This hasn't been a problem in good quality logic gates since the 1980s. To cover all cases, a small increase of reliability (or speed boost) may be obtained by using one pull-up resistor. In most cases, the resistor can be skipped and the redundant input can be tied high. To be safe and use the least components, the inputs are ganged. The loss in performance is usually acceptable.

Anyhow, when I see Nick Gammon's 24KB RAM scheme or akohlbecker's beautiful decode scheme, I know that someone has been thinking and is not blinding copying.

[Michael]

Sheep64 wrote:

Partly as an exercise, I spent eight days working on address decode schemes. The best I could devise was one 74x139 for 4*16KB segments and read/write qualification. I've seen both parts used separately but I'm not sure if they have ever been used together.

I've think I've seen the single-chip decoder and qualified r/w circuits used together before.

[GARTHWILSON]

Michael wrote:

Sheep64 wrote:

Partly as an exercise, I spent eight days working on address decode schemes. The best I could devise was one 74x139 for 4*16KB segments and read/write qualification. I've seen both parts used separately but I'm not sure if they have ever been used together.

I've think I've seen the single-chip decoder and qualified r/w circuits used together before.

also viewtopic.php?p=88176#p88176 and viewtopic.php?p=84747#p84747

[BruceRMcF]

BigDumbDinosaur wrote:

BillG wrote:

A more foolproof solution is to require that all labels be terminated by a colon (:)

I disagree.

Most assemblers in current use make terminating a label with a colon optional, if they allow a colon at all. Why force someone to accommodate yet another syntactical rule?

Relaxing the rule that some assemblers had back in the 1970s is, indeed, a convenience for those using the assemblers in current use, but most assemblers for small systems are cross-assemblers, and are not attempting to achieve the space efficiency of the 1970 era in-system assemblers, and the trade-offs are different.

It remains the case that requiring the terminal ":" for labels, is a simple strategy to simplify the distinguishing of symbols, opcodes and labels.

[okwatts]

I have noted a peculiar behaviour that is reproducible in my implementation on SBC2.7 (from Rich Cini). For those who have this running on their version be it Ben Eaters or other could you try out this and report if you have the same odd behaviour.
1.Load the example program examples/pas/guessing_game.pas
2. info for line length etc
3. list the program
4. do info again
Question "Do the results of info match?" In my case the list and subsequent info show that the file is now 109 lines not 115 as in the original load. I am asking this at the risk of exposing myself to ridicule for overlooking an obvious goofup in my implementation when other things work as they should.
Thanks

[Michael]

May I ask if this is the VASM package Nick is using to assemble his G-PASCAL source files, please?

Also, has anyone looked at what it would take to replace the TSB and TRB instructions in the code so that G-PASCAL will run on a Rockwell CPU?

TIA... Happy Holidays. Mike