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

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

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

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.

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):



to:



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

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:



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:



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



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

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

vs


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:

vs

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

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.

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).



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.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

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

_________________
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?

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.

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

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