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

[GARTHWILSON]

Michael wrote:

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?

All brands of 65c02 have TSB and TRB.  That includes the Rockwell R65C02 and its variants.

[BigDumbDinosaur]

Michael wrote:

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?

I’m assuming from your question that you are referring to the R6502, not the R65C02.

TRB and TSB are “two-fer” instructions, in that they manipulate bits but also perform a different internal operation that clears or sets z in SR according to what is in the addressed location prior to it being changed. That is, these instructions not only clear (TRB) or set (TSB) the specified bits, they tell you the state of the specified bits prior to the transformation.

You could replace TRB with:

Code: Select all

          LDA #<BIT_PATTERN>
          BIT <ADDRESS>
          PHP
          PHA
          EOR #%11111111
          AND <ADDRESS>
          STA <ADDRESS>
          PLA
          PLP

The following code could replace TSB:

Code: Select all

          LDA #<BIT_PATTERN>
          BIT <ADDRESS>
          PHP
          PHA
          ORA <ADDRESS>
          STA ADDRESS
          PLA
          PLP

The above would be the equivalent of:

Code: Select all

          LDA #<BIT_PATTERN>
          TRB <ADDRESS>

...and...

Code: Select all

          LDA #<BIT_PATTERN>
          TRB <ADDRESS>

...respectively.

BTW, the above sequences highlight why one should avoid the NMOS 6502 if possible.

[Michael]

GARTHWILSON wrote:

Michael wrote:

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?

All brands of 65c02 have TSB and TRB.  That includes the Rockwell R65C02 and its variants.

I see now. Rockwell has all but the WAI and STP instructions.

Thank you, Garth.

Happy Holidays...

[okwatts]

Just a followup to my post from May that the peculiarity I was seeing then was at specific memory locations and was likely due to hardware issues in my SBC2.7. I came to this conclusion after trying out GPascal using Plasmo's CPLD trainer (I adapted to running from RAM and just used the Char in and out routines in the monitor). This worked as expected without the hiccups I had noted on my SBC2.7 machine. Unfortunately I haven't added the VIA as plasmo had, so I miss out on the additions that Nick made for I2C SPI etc. But the Pascal compiler and assembler/editor work nicely.

This caused me to revisit the SBC implementation. I had specific memory locations that were failing in a repeatable manner. I wish I could say that I put the scope on and diagnosed the issue but I didn't. Instead I had used this board for evaluating various RAM chips as per the thread by adrianhudson in newbies "strange memory write problems" (viewtopic.php?f=12&t=7371) where I similarly to adrian had issues with the Alliance AS6C62256 chips. As a result I had ordered some 74HC logic to further evaluate things. I had run plasmo's memory diagnostic on the SBC previously so I replaced the 74LS chips (74LS00,74LS30,74LS138) on the SBC2.71 with their 74HC equivalents and the memory tests results were the same, passes for the HM62256 and UT62256 but fails for the Alliance variants. I then inserted my GPascal ROM (using the ACIA rather than VIA) and now I no longer have the specific memory weirdness I had in the past. It appears that I likely had this issue all along even though I had thought everything was working properly and I had built the board according to the recommended components. Even plasmo's memory test didn't reveal that some locations were failing under certain conditions.
So this leaves me with a better working board but I haven't specifically sorted out why it worked for most things but occasionally failed.
To be be diligent I should repeat all this with a scope attached to try and better understand what is happening. I fear my limited hardware skills might not be up to the task.

The upshot is I have a more reliable board but there still is an issue with the Alliance chips on this board.

I hope that I can get a clearer understanding of exactly what is going on and I will report back my findings.

[plasmo]

Larry,
Did you save all the parts that were causing the memory problem and are you able to restore these parts and see the problem again? I'm wondering whether AS6C62256 is TOO FAST that caused your memory problem. If raising the 5V causes more problems but lowering the voltage reduces the problem, then it is a strong indication of system noise due to fast components. For intermittent problems like this, you want to find an operating condition that cause the problem to show up consistently and then do a fix that makes it go away completely. What I heard from your description sounded like a system noise problem rather than a mechanical intermittent problem. These intermittent problems are difficult to solve.
Bill

[okwatts]

I do have all the parts and I will try and investigate further as I bought the faster Alliance Ram for the SBC2.7 board because I did want to up the Oscillator from 1MHz to 4 MHz where it is now. It seemed to work without changing out the RAM so I never tried them until adrianhudson had his issues. I will try to get more real information over the holidays and report back.
The odd thing even with the HM62256 RAM is it appeared to work fine. I could load pascal programs, compile and run. ( I also had been running Paul Dourish's SECND forth for a year or so on it with no apparent issues.) The oddities showed up when I listed the program as I alluded to in my earlier posting in May. It always zeroed out a specific memory location ($c55) which I would correct using a poke command and then it worked until I listed again and it was always the same memory location. I was suspecting that in my adaptation to the SBC board I had messed up the software or had uncovered a bug. I had this same behaviour if I used the serial through the VIA just changing the addresses for the VIA on the SBC2.7 or whether I used the ACIA routines I patched in. I have since noted when I used the list command for a different range of line numbers I had corruption in different memory locations some of which I couldn't correct with a poke. The odd thing was that the programs would compile and run it was only when I listed them that issues showed up.
That's what made me suspect issues with GPascal and not my hardware. As you said intermittent problems as VERY pesky!

I will attach the schematics from Rich's SBC2.71 board, in case others with more knowledge than I can see any obvious flaws. It seems to be a reliable design that originated with Daryl Rictor. The only thing I noted in the adrianhudson case was the CLK qualifying the read/write was from the PHI2 out on pin39 rather than the input CLK on pin37.

EDIT: BigEd, this is starting to go off topic a little so perhaps it should move to the thread discussing "strange memory write problems".

[BigEd]

(Indeed, a new thread might be an idea, but it's in your hands - only Garth can re-thread, and I'm not sure I can remember the last time he did it.)

[okwatts]

For the sake of completeness I note: It appears that my issue maybe just have been due to a flakey 74LS00, I only had one and used it. I reverted all the glue to the 74LS varieties and then replaced the 74LS00 with an old 74H00 which seemed to work reliably. I'm still investigating the RAM chip situation, which I will post in the adrianhudson problems with memory thread, as noted above, if I get more definitive info.

[Michael]

I finally got G-Pascal running on a simple 64K SBC prototype. It just would not receive characters from the Terminal (using Rockwell or WDC VIA chips) until I got rid of the 1K resistor. Could eliminating this resistor be a potential problem?

The SBC features 64K RAM minus the 8K I/O area ($6000..$7FFF). The 64K 'A' or 'B' half of the 128K Flash ROM is copied into RAM at power-up or reset at a nice leisurely 1-MHz rate and a "long press" of the <SYS> push button will program the 64K 'A' or 'B' ROM with a copy of RAM (takes about 7 seconds). An Arduino Nano clone functions as ROM Emulator to load operating systems, programs, and files into RAM for iterative code testing and to program 128K 39SF010A Flash ROMs without a ROM Programmer. The Nano is also tasked to provide a 1, 2, 4, or 8-MHz CPU clock.

Thank you for an awesome package, Nick. It's an incredible and impressive work product.

Cheerful regards, Mike

<added 25-Jan-22>
I'm geeked. The SBC seems to be working with an 8-MHz clock after replacing the Rockwell parts with WDC parts (W65C02 & W65C22) and setting the serial baud rate to 38400.

[okwatts]

Very nice compact setup using the "skinny" ram and hiding them under the larger chips. The G-Pascal system is very nicely done with all that it offers for development and interfacing through the 6522.

[Michael]

Daryl Rictor's SBC2OS also looks pretty nice. I wonder how difficult it might be to modify SBC2OS to support Nick's bit-banged VIA serial interface? If it can be done, the modified SBC2OS might be a good candidate for the 'B' ROM on my SBC prototype.