floobydust is right:

Since it's cb3rob's first 6502 project, we shouldn't exclude the possibility of a software related problem,
or a hardware design related problem.

Checking those two things would take less time than "tearing apart" the hardware,
so we better have look at the full source code and the schematics first.

// I probably had spent too much time with digging through odd hardware, so I might be "biased".

ok, after resoldering the entire board (and yes, pbsn, not that crappy rohs stuff), cleaning off the flux residue -again, etc (i so need a wave soldering machine , replacing -all- of the chips with new ones and encountering some overheating max232's for whatever yet unknown reason (real ones at that, the intersils don't do that, so back to the intersils - maybe the max232CPE's don't like foil capacitors

measured all busses and clock lines with 'no chips on the board'... 0 ohms to what should be connected, a few megaohms to what should not be connected, as should be, no weird interconnects or interference there. just the internal resistance of the ds1813 which is hard soldered to the board obviously and the pullups and capacitors, all of which only are measured at the points to which they should connect and nowhere else.. so the board seems ok... but guess i'll just populate a second board to see if that also screws up anyway. (yet another hour of hand soldering...)

i found this thread which just so happens to give the same error with the same setup.
(65256 SRAM + AT28C256) EEPROM /WRITE tied high with a 3.3K pullup permanently, CPU R/W ran through an inverter to provide write to the rom. but not gated with PHI2 at all. (looking at the datasheets that would only be nessesary to -write- the eprom which could also be done only at unacceptably slow clockspeeds, impose security problems and probably break the eeprom early on due to the users probably just using them as ram instead ..

not entirely sure if it is nessesary to gate the clock with either CE or /WRITE or /READ on either AT28C256 or 65256'es (other than for writing the eprom which seems to have cycles). the funny thing is the stuff does pass all memory tests, forever.

- writing the addess bus line to the first address of that segment for 0000 to 4000 (obviously not the rom), then reading them back to make sure no address lines are interconnected or broken.
- writing incremental values to -each individual address- one by one, reading them back instantly (any capacitance on the bus is cleared by the next instruction fetch anyway, no need to reset the bus in between like it is with caching cpus should a chip not be present at all)
- ehbasic's own memory test (writes $55 to it or something to check the ram size upon startup, something simple which doesn't take 2 minutes like ours
- the rom checksum always matches that of the same rom in the emulator, no problems there, it reads the rom just fine.

the thing can run these tests for days on end without problem, it runs things like wozmon or our own monitor perfectly fine, write values to ram, read them back hours later, loading some smaller programs, no issue.

so far every attempt to run a basic however, results in some pretty weird **** that doesn't occur on the emulator.

address map:
0000-7FFF RAM
8000-FF00 ROM
FF00-FF03 ACIA0
FF04-FF07 ACIA1
FF08-FF0B ACIA2
FF0C-FF0F ACIA3
FF10-FF1F VIA0
FF20-FF2F VIA1
FF30-FF3F VIA3
FF40-FF7F RESERVED FOR 4x 16 register ethernet chips such as the cs8900a in future versions but for now maps to rom
FF80-FFF9 COMMODORE COMPATIBLE KERNAL JUMP TABLE (LOAD SAVE CHROUT CHRIN etc IEC bus functions, also to run commodore basics).
FFFA-FFFF RESET VECTORS


address decoding is 2 nand gates dong the "$FFxx" part and 1 nor gate hooking things together and doing the XX%00X part.
feeding into a 74HC139 splitting it up into 4x a 16 bit range using the first one to split it up in it's second half into a 4x4 byte range

an inverter on RW to provide the weird read/write crap for sram and eeprom... bbbbut... no gating with any clock. the datasheets actually are pretty clear about no clocking being nessesary...

(unless ofcourse the 65C02 would hold the write line active while the address or data already changes, that would corrupt the RAM, but then again, that would also show up in -every other program and memory test out there- even when writing single bytes and instantly reading it back, after all if /WRITE would still be low it would overwrite the address the LDA came from to check it.)

all weird 65C02 signals pulled up with 3.3K (nmi reset so rdy ... one more i don't remember right now either way despite the ds1813 having it's own internal pullup we've found it to be quite weak so that also has an extra one)

full size can oscillators capable of directly driving 25ma which should suffice for 20 such boards with just a single one go anyway.
(both for rs232 driving all 65C51s at once and for the system clock)
rs232 clock: 1.8342 mhz
system clock: 2.0000 mhz (the thing is planned for 6.000 or 8mhz (depending on the AT28C256 which doesn't seem available any faster than 150ns, kinda limiting it to '6 and a bit') but we can't source WORKING 65C51's in bulk, rated for more than 2mhz atm
(let's not overclock the acias shall we

at this point i do kinda suspect the ram somehow has to be gated with the clock tho. hmmmmm...

viewtopic.php?f=5&t=5186
^^^ that forum thread. exactly the same error

viewtopic.php?f=12&t=4556 <- hmm. simular issues, bad 65c02.. hmm thing is the ones i have are all from the same production batch ordered about a year ago. other than that just 65816's in stock and some old mos ttl ones.

as people seem to get this to work on -breadboards- i somehow doubt that the problem would be the pcb.. but it could be that the clock is not AND'ed with the R/W signals. but then that should be reproducable and also pop up in memory tests, which it does not, hmmmmm also the entire code runs perfectly fine in the emulator (which exactly emulates the board with just a single via and poops out warnings if the code is trying to do something weird such as trying to write to unimplemented i/o chips or trying to write to the ram, which btw it exatly emulates in that 'nothing happens' if it does other than a big warning on the output)

If you're assembling your own EhBasic, you should check against this discovery:
> it appears that the low byte of the Ibuffs address cannot be $00.

Hmm... that's unlikely.

Another possible explanation is that one of the RS232 driver outputs "went short circuited to GND" somehow,
maybe the Intersil minds such things less than the Maxim, but I'm not sure.

If something would be wrong with the TX line, you sure would have noticed.
But if flow control in the PC is disabled and a handshake line went short circuited to GND...

Would be interesting to know if the Maxim still heats up without a load at the RS232 driver outputs.

;---


RAM /WE should be gated with PHI2: /WE only should be able to go LOW when PHI2 is HIGH.
That's because address bus and R\W might be not stable for some time after the falling edge of PHI2.
An ungated RAM /WE could cause spurious writes to "random" addresses (if the RAM is fast enough).
Please check.

BTW: nice memory layout !

You do need to gate the write timing with clk2.... I'm posting a schematic for my older CPU board, which has an I/O page at $FE00 with 8- I/O selects. With an I/O board attached via a short 2-inch cable, I'm running it at 12MHz (70ns RAM/EEPROM) with W65C22S and W65C51 (an older chip that WDC sent me some years ago, which works for transmit).

So far, every Atmel EEPROM (rated at 150ns) has run fine at 10Mhz with the board set... I needed a 70ns part to get past that.

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

One of the other threads mentioned had the fix of swapping the RAM for a different speed and manufacturer. It seems likely that any unsafety in the timing of the glue logic could be covered, or exposed, depending on details of the clocking, the CPU, and the RAM.

ok.. so time to build the next one with an ugly piece of veroboard sitting on top of the rom/ram slots on pin headers lol. or just glue the quad nand gate up side down to the board for now lol. more changes for the next prototype pcb production run but i guess we'll just test with one of this production run. can't sell these boards anyway (at least not to consumers in the eu) as i explicitly ordered them with lead HASL lol.

ccflag = $0300 ; BASIC CTRL-C flag, 00 = enabled, 01 = dis
ccbyte = ccflag+1 ; BASIC CTRL-C byte
ccnull = ccbyte+1 ; BASIC CTRL-C byte timeout

VEC_CC = ccnull+1 ; ctrl c check vector

VEC_IN = VEC_CC+2 ; input vector
VEC_OUT = VEC_IN+2 ; output vector
VEC_LD = VEC_OUT+2 ; load vector
VEC_SV = VEC_LD+2 ; save vector
IRQ_vec = VEC_SV+2 ; IRQ vector
NMI_vec = IRQ_vec+$0A ; NMI vector

; Ibuffs can now be anywhere in RAM, ensure that the max length is < $80

Ibuffs = IRQ_vec+$14
; start of input buffer after IRQ/NMI code
Ibuffe = Ibuffs+$47; end of input buffer

Ram_base = $0400 ; start of user RAM (set as needed, should be page aligned)
Ram_top = $8000 ; end of user RAM+1 (set as needed, should be page aligned)

guess it's not 00...

not sure if that 'broken' 65c02 (exactly how does one 'break' a 65c02 in -that- way anyway, especially since the problem occurs with 4 of them i took out of the same tube so far in that other post was replaced by a 65c02 of the same manufacturer/production batch or wether the bus timing thing could be considered a bug. "only works RELIABLY with some speeds/models/makes of sram" isn't good enough lol. guess we'll just have to add the extra logic to the board. and maybe some extra logic to also work with 65c816's in the same slot (adding the latches anyway can't hurt i guess, if we make the latches 74hct ones it would even work with nmos chips

none of the rs232 outputs are shorted to ground btw. and furthermore, even if they were, an rs232 line driver, being what it is, should provide a high degree of resistance to ****ery not saying they should built optocouplers -into- them but pretty close to that, yeah. lol. ESD protection and current limiting resistors are the least one would expect by default. guess they have that but that something else is wrong, as the maxim ones get very very hot. even in slots not populated with 65C51 at all. the same WIMA MKS1 1uF foil caps on everything. which should be fine for all 'max232 clones' even the ones that are specified for 0.1 uF (it only becomes a problem if you take it well over the original specification of 1uF where the IC gets burned by the initial charge amperage of the larger caps, if you'd use, let's say 47uF elcos). there can after all always be some rat eating your underground cables between one building and another and you don't want your control systems to catch fire because of some shorted wire half a mile away i therefore somehow guess the maxim chips have that too and something else went wrong there (they got to about 60C before i pulled them out and put the intersils back in

I suspect it's not so much that chips are broken, as that many designs don't have margins against the full spec of every chip: max and min timings, hold times, setup times, clock skew. So, when you change a chip, you never get something which behaves exactly the same, and if your design is outside spec, it's a lottery.

Even worse than not having margins is not even controlling something as you should, and relying on relative delays to get one signal before another.

If you design by trial and error, as many do, you may fall foul of mysterious failures. Arguably, you then get to enjoy a debugging phase!

most timing diagrams aren't as readable as the ones i'm used to from the old days tho lol. let's just say that the ones in the commodore 64 programmers reference guide are a lot more clear than the ones currently pooped out by WDC (their datasheets could be a bit more clear on a lot of things, such as putting -numbers- next to register names (specifically the via and acia datasheets of WDC are better replaced by 1979 ones of other makes at least there you don't have to run a whole lookup library to link register names back to address line state tables to numbers and they just print the numbers where you expect them, and timing diagrams are more clear in the old ones the wdc via datasheet in specific spends more pages on timing between cpu bus i/o and output on gates than it does on the relation of the clock to the input latches (as in who -cares- that the diskdrive may take a few milliseconds to get the command anyway, we wanna know if it talks to the cpu of choice correctly, thats the only timing diagram that really matters and it should be -clear- and not come with a lookup table of abbriviatiosn spread over 3 pages

ROB TACTICAL DATASYSTEMS
65C02 DEVELOPMENT BOARD
FIRMWARE REVISION: 01-01
ROM CHECKSUM: 47
STARTING MEMORY TEST
MEMORY TEST OK
MEMORY DETECTED: $8000
STARTING BASIC

31743 BYTES FREE

ENHANCED BASIC 2.22

READY
10 print
20 PRINT "HELLO"
30 GOTO 10
LIST

10 print
20 PRINT "HELLO"
30 GOTO 10

READY
10
LIST

20 PRINT "HELLO"
30 GOTO 10

READY
POKE 2000,4

SYNTAX ERROR
READY
POKE (2000,4) <--- DEAD.

sooo... as you can see. it nicely plays along with storing programs in ram and all that... but a 'poke' or a 'peek' nah. instant death. also things like N=4 are instant death.
it's almost like it's trying to store it someplace it cannot write to but i know it doesn't do that as then the emulator would nag about it.
i'd have to check wether it happens to do some back check if the poke was actually executed or something and then magically dies without giving an error or returning to warm start (you'd expect an os like basic to be able to cope with such things as variables not being stored in ram without crapping it's guts all over the place and dying on you
(should writing to the ram not work out something like 'ERROR: ACCESS DENIED' would be more appropriate than instant death but maybe it just dies upon trying to read the rom instructions, however that is far less likely to get corrupted than accidentially writing random values into ram before or after the right part of the clock cycle (the address bus most likely would always be correct at the point the cpu tries to read it anyway, and it cann't write to the rom in the first place, so that's highly unlikely to be the case, probably something to do with the ram, but yet, storing programs works perfectly fine... until you try to run them or set variables or peek()

hmm. guess i can scratch away most of the lines where the inverter sits that drives the leds (the R/W line led turned out to be rather useless anyway, don't put a led on the r/w line kids, you won't see any change on that anyway no matter how much STA's or LDA's you do in a row. it doesn't even visually get more dim (already tried to do the same with all chipselect lines on some experiment board but it's just way too fast to see, even on analog scopes (without memory, but then again, also without ms windows, which is a good thing you hardly see the chipselect on let's say an acia (plus the fact that those things are actually only good for showing repeating patterns and average voltage levels (no single 1 microsecond 10kv peek will show up in an otherwise 0-5v signal) as it actually writes that line a few 1000 times while you look at it once, the rest is crt phospor surrogate doing it's job i expected it to be 'half dim' when a lot of writes were going on but putting a led on the rw line is useless for debugging purposes (other than hooking the scope to that output as being behind an inverter it cannot harm the actual bus there then drop the nand gate into that socket for the gating with the clock and keep the extra port for inverting the reset led (also not driven directly off the reset bus