the disadvantages of real hardware. lol. the 65c02 doesn't exactly have an lcd display on it that displays all it's registers like emulators do but on emulators this problem would never occur in the first place (unless someone cooks up an emulator that actually runs transistor level logic and not just emulates the 'instructions' and their outcome

As noted previously... the IRQ/NMI/BRK routines don't seem to be handling an actual interrupt... if they (NMI/IRQ) are all turned off (in hardware, software?) then you shouldn't be going down that code path anyway. The NMI line should be held high (usual is 3.3K to +5) and if you want to trigger it manually, it should be de-bounced.... most folks, including myself, use a DS-1813 for this.

Also, there is some odd timing if you use them for both NMI and RESET... but I know that BDD's POC designs use it on both lines and he seems to be fine with it. My last project used a TL7705B for RESET with the timing set (via RC constant) to be longer than the specification range of the DS-1813, which is used for NMI as a Panic button.

As you're now working with actual hardware, it can be difficult to determine if you have a hardware design or wiring problem or if your software isn't working with your hardware. Being somewhat new at the 65XX hardware/software, you can easily find yourself in a "catch-22" situation.... you can't verify properly functioning hardware or software without a lot of diagnostic effort. As I don't recall you showing a schematic for your system, there's no easy telling if your problem is HW, SW or possibly both.

One alternate method to diagnose the problem is to run some software that is a known functioning piece of code, provided of course, it's properly assembled/linked for your hardware I/O addresses, etc. Fortunately, there's a lot of good code already around for this. Dary'ls SBC-2.5 source code is accessible via his website and I also posted my BIOS/Monitor for driving a 65C51 and 65C22 with CMOS code running on the W65C02S. I know my code better (than Daryl's code)... which supports full-duplex interrupt-driven and buffered serial I/O using RTS/CTS handshaking for the 65C51 acting as a console... and both timers of the 65C22 being interrupt-driven for a 4ms timer used as a RTC and the second timer for a 1ms hardware delay. Basic 65C22 port accessed is also included plus a fairly rich monitor.

You might want to take the approach of using either piece of code and see if your hardware works with one or both... if it doesn't, then it's a pretty good bet that you have a hardware design or wiring error. If either piece of code does run, then you'll at least have some known source code that you can use to help debug your code. Continued good luck with your project... and there's lots of expert help out here... just ask.

_________________
Regards, KM
https://github.com/floobydust

There's also the debugging page of the 6502 primer. It's all I've ever needed.

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

Since the schematics and the complete source code haven't been posted, I can't give much advice.
Running untested software on untested hardware might be "the highest degree of difficulty".

The pictures from the hardware show some tinkering with 6551 and RS232.

Would suggest to write a short piece of code, that just initializes the 6551 and then does nothing but an infinite loop
which constantly transmits a Byte through the 6551, without making use of interrupts.
The shorter the code, the more easy tracking what happens in the computer with an oscilloscope.

Once the 6551 transmits characters, the next step is to modify the loop to make the 6551 echo characters sent by the PC.

If this works, try to implement a monitor program for checking the rest of the hardware.

BTW: another idea is to modify the hardware for giving the 6551 the same address like it has in Daryl Rictor's SBC2,
and then to go with the (unmodified) SBC2 software for a while for having a starting point.


You got to be creative. To put it this way:
Ninjas are supposed to be able to pick up anything that lies around and to use it as a tool for solving a non_technical problem.
Engineers are supposed to be able to pick up anything that lies around and to use it as a tool for solving a technical problem.
Good luck !



Edit:
If the 6551 doesn't make it into the loop and you only have an analog oscilloscope,
sending a maybe 100Hz square wave generated by a NE555 or such into the /RES input of the CPU
might be helpful for hardware debugging.

is there any reason for commodore basic 4.0 (ripped of the pet 8032) not to work on a WDC65C02
as in it makes it through ALL of the tests (addressline test, full memory test with all values, rom checksum), the 2 so far fully implemented cbm kernal functions (chrout and chrin) work, in fact the whole thing works -on the emulator- and nicely allows for entering basic programs (although the so-far missing keyboard buffer makes backspace a bit tricky but that emulates the NMOS instruction set..

when running it on the actual hardware however, it gets to this point:

ifndef cbmB1
;
; Display "xxx COMMODORE BASIC xxx"
;
LDA #>CBMBAS
LDY #<CBMBAS
JSR OPSTRA
endif
;
; Calculate and display free space value
;
LDA HMEPTR
SEC
SBC TXSPTR
TAX
LDA HMEPTR+1
SBC TXSPTR+1
JSR A3C59
;
; Display " BYTES FREE"
;
LDA #>FREEK
LDY #<FREEK
JSR OPSTRA

prints out the CBMBAS string *** COMMODORE BASIC 4.0 BLA BLA ***
prints out the 2 trailing (and translated for normal terminals by the bios/kernal code) CRLF's
then on the emulator it nicely comes up with 32KB basic bytes free. but on the 65c02 board it magically prints out an extra CR (yet again translated to CRLF by the bios) and then dies.

the JSR A3C59 is a huge subroutine that prints the number in A and X as a decimal (actually as a 6 byte floating point if i read this correctly, but it shows as decimal

my suspicion at this point is that the 65C02 does 'something different'.. causing it to crap up somewhere in that huge subroutine calling 2 other subroutines and dying along the way, resulting in the extra enter somehow.

set up traps in the emulator to check for any other operation (basic trying to access i/o directly, trying to read or write to rom locations, that sorta thing) none of that happening. basic nicely calls kernal functions (mainly chrout, chrin and 'stop' (not implemented yet as clearly the documentation is lacking, also the only documentation was actually for the c64 probably doesn't need carry and zero set upon return to 'stop' but an actual jump to warm start, as none of the code that calls it handles it's return value in any way within basic).

now, at least cbm basic v4 actually -gets- to the "commodore basic v4' screen.
basic v2 either fell staight through to warmstart, printed ready, and then crapped up after entering the first letter (sometimes a line)

(basically all commodore basics are the exact same code with a bunch of ifdef's all over the place... my suspicion is that 'somewhere in something called by the coldboot routine' there is something 65c02's can't do the same way 6502's do literally pulled all chips but the acia out and the effect remains the same.

an actual nmos 6502B gets 'a bit further' (somehow skips the vendor/version header, skips the 'xxxx bytes free' and falls through to warmboot, printing 'ready.' and BREAK, and then crapping up with binary diarrea but that is to be expected as it can't possibly drive boards this size full of cmos inputs directly (heck an nmos 6502 can't even drive an nmos board this size without pullups and bus drivers all over the place but doesn't have enough power to drive the addressdecoding and the sram (and probably the 65c51) and therefore fails the memory test - not very reliable results there.

if people did get unmodified commodore pet basic's to work on 65C02 boards then i blame that crappy veroboard pretending to be a 74hc139 until the real ones arrive

even filled up the (non used parts) of the rom with random binary crap to see if the checksums still mached those calculated by the same rom in the emulator, and they do. so, not some electrical problem where it suddenly starts to crap up if a lot of address lines are '1' or something, the thing has also been printing 'hello world' for about a day in a row before, so no issues with the rs232 voltage generation. it seems purely 'microsoft basic on a 65c02 rather than 6502' specific.

the only commodore i've ever seen that had a 65c(s)02 (the ones with the missing BIT instruction is a vic-20 that also had everything else changed and most definately wasn't used to run 'basic', so not entirely sure if it would even work if you dropped a 65c02 into an actual pet and kept the original roms.

Well, I have a couple fully socketed Vic-20 machines here... have had them for years. I replaced everything but the ROMs and 6561 chip with CMOS replacements and a Rockwell R65C02... and the VIAs with either R65C22 or W65C22N chips. Both work perfectly fine.

However, when using a W65C02S CPU (pin 1 lifted and the other unused signals tied via 3.3K to +5), it boots to the ready screen and craters shortly after that. As the Vic-20 uses the 6561 to generate all system timings, plus uses the other clock outputs from the CPU, that's likely a cause for problems... as WDC themselves note in their datasheet that the clock outputs from the CPU should not be used for any system timing as the results are not guaranteed.

The PET.... I'd have to dig out the schematics, but if they also use the clock outputs from the NMOS 6502, chances are you'll have issues using the W65C02S in it's place.

As for Basic (which is Microsoft Basic), there's mainly the one source code that has several variations based on which machine it was used with (on the Commodore side)... and then some other changes for floating point, short messages vs long messages, etc. The Pagetable code should assemble okay, but I only use the WDC assembler/linker for my stuff and haven't gotten around to changing it all... yet.

On the Basic front, I recently modified Lee Davison's Enhanced Basic, which was based on Klaus' updated version. It now runs flawlessly on my SBCs... one which uses a R65C51 UART and a newer one which uses a SCC2691 UART. It's just a single assembler file and the only thing you need to change are the vector addresses for Character In, Character Out, Load, Save and in my version, an Exit vector, which returns to my Monitor code. It's quite trivial to get it working on any 65C02 system... but it absolutely requires the CMOS CPU as it uses many of those unique instructions/address modes.

You're welcome to try my code if you like... or I'm pretty sure Daryl also has EhBasic integrated into his Monitor code as well.

_________________
Regards, KM
https://github.com/floobydust

André Fachat has some PET related things on his homepage that might be useful.
He had built his own PET4032 using the CPUs: MOS6502, Rockwell R6502AD and R65C02P4.

Felt a need to add some info about the C64 Basic plus Kernal there.

Hmm... also, take a look at LUnix, GeckOS and Contiki.

hmm.probably some hardware issue. inserted ehbasic, simular issues there although it gets a LOT further.

10 PRINT "HELLO WORLD"
20 GOTO 10
RUN

TYPE MISMATCH ERROR IN LINE 10
READY

and once again it runs perfectly fine in the emulator, just like commodore basic 2 and 4.
time to take all the chips but the clock oscillators off the board again, and measure the whole thing through... or just assemble a second board and see if the problem happens with that one too.

the weird bit is that it can run it's memory tests of all sorts for days on end and also poop out the same line of text over rs232 for days on end (which also involves that other part of the address decoding) but somehow it doesn't seem to run basic very well at this point. hmmmmmmm.

10 PRINT "HELLO WORLD"
20 GOTO 10

READY
RUN

TYPE MISMATCH ERROR IN LINE 10
READY
A=4
<dead>

ok. so it works fine.. until you try to use variables of any sort. lol. microsoft would probably have shipped it by now.

...Besides that M$ has quite a reputation for slowing down computers (not only PCs) with odd code for 40 years+.

It's an odd effect you describe there, I never had anything like it.
Hmm... in which address sequence the memory tests did check the Bytes ? Just "incremental" ?


Out of a gut feeling, I would say that maybe one of the address lines between CPU and memory might be "open"\broken.
Would suggest to inspect the PCB with a magnifying glass, especially the parts where a trace goes to the pad of an IC pin.

Don't know where the PCB was manufactured, but I remember to have had some trouble with defective vias some years ago...

;---

Hmm... well.
"Shotgun debugging" would be, when you solder wires between the IC pins according to the schematics in parallel to the PCB traces.
If the computer still doesn't work then, something is wrong with the schematics.
If the computer works then, cut away one wire after the other until it stops working.

Edit: resorting to the resistor color code when soldering wires for bus lines is helpful for not losing overview:



This brings back memories. 68020 + FPU and 32 Bit data bus.
That part when you step out of your workshop, look around and say: "Hey, it's summer again ! What year do we have ?"

Edit2: when soldering a lot of wires, for not losing overview it's also helpful to print out the schematics on paper,
then to scratch every soldered wire in the schematics with red Edding (TM) or such while soldering.
...I really should have done that back then... if there were any schematics, that is.

Ok, so I'm not the expert when it comes to Ethernet, but after looking around a bit starting with this list,
to me three chips which seem to support an 8 Bit parallel CPU interface looked interesting:

SiLabs CP2201 10 MBit/s MAC+PHY, QFN28
Microchip LAN9250 10/100 Mbit/s MAC+PHY, QFN64
Microchip KSZ8441 10/100MBit MAC+PHY, LQFP64 //don't know, how long it will stay in production

Nothing in DIP package, sorry.

I would suggest posting a schematic of your system.... it might help for some extra eyes to look at it. Even if the memory test runs fine, there's still the possibility that you have some HW issues with the I/O, although wiring up 65xx peripheral chips is generally trivial, there's still the timing of it all.

I would also look at page zero usage... between your code that is running the UART, VIA, etc. and that which is used by either BASIC implementation. That's one area that I (had to) change quite a bit... as my BIOS/Monitor uses locations from $B0 - $FF, so I made all of EhBasic page zero use consecutive from $00 up to $85. And of course, stack use... ensuring that it's not getting over run and that CPU registers are being preserved as needed between code bits.

_________________
Regards, KM
https://github.com/floobydust

A sketch of the memory test would be helpful: there may well be failure modes which are not covered.

Hoglet's trace decoder would also be very useful. The hardware is inexpensive and it's a quick way to find out where things go south.