time for a little experiment *inserts 4.0000MHZ osc* (overclocks the single acia but who gives a crap about blowing up an acia, 10000 more where we got these from
instead of using slower sram, what if we make the system faster.. hmmmm.

nope. still

10 PRINT "HELLO WORLD"
20 GOTO 10
RUN

TYPE MISMATCH ERROR IN LINE 10
READY

ok... *looks evil*. how about an 8MHZ one.

hmm the 2mhz acia seems to play along at 8mhz (at least, for a while)... memory test is a bit faster (about the same time it takes on the emulator which is also set to 8mhz)

CB3ROB 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 "HELLO WORLD"
RUN

TYPE MISMATCH ERROR IN LINE 10
READY


nope. making the system faster to pretend the ram is slower doesn't work lol.

right then... time for a little cp HARDWARE/BOARD-REV-A HARDWARE/BOARD-REV-B and open kicad again. lol.
but first let's try it with a little gue and wires sticking out.

as none of the pcb manufacturers i contracted seem to charge per hole they have to drill and plate through anymore (which used to be a thing in the past anyway) i should just have implemented a piece of experiment board -on- the actual pcb i think. for such modifications as 'oh we need another logic gate chip or a weird ass ethernet controller on a piggyback board'

We had a couple of recent incidents where clock skew was the root cause issue, but the symptom appeared like "ram is too fast."

hmm. considering that the ram and rom don't use the clock at all right now and that the oscillator is right next to the cpu i somehow doubt that. maybe after it would have travelled all the way to the acias but the error seems to mostly occur several cycles after the acias are already done outputting stuff (i'd say between you pushing enter on N=4 in basic and it actually trying to do something with that N=4 several 100s if not 1000s of cpu cycles have already passed during which the acia was not selected at all clock skew would only affect things that actually -have- a clock line sram and at28C256'es do not have such a thing

from the looks of it it could also do with a little delay before sending the ansi clear terminal escape code upon startup as it's probably still busy charging the max232 caps by the time it gets there sometimes when applying power rather than pulling reset

As I recall, it was a matter of the skew from the input to the output clock of the 'c02, and the fact that the 'c02 is particularly fast. If you're thinking in terms of cycles, you're still one level too far up. It's in terms of nanoseconds that things can go wrong, and it's more subtle than just 'are the circuits fast enough.'

glue is drying on 4 sockets melted together with a 74hc00 with 2 wires coming out to other stacked sockets to intercept 1) phi1 and 2) /WRITE for the ram. /WRITE for the rom is tied high anyway and /READ probably doesn't matter as it won't corrupt the ram and the cpu won't latch the data in if it doesn't feel like it anyway. the whole thing should plug in place of the inverter and under the ram when the glue is dry and then we shall see

kinda running out of matching sockets due to all the ghetto workaround boards needed so far (mainly due to the proper parts not arriving in time and thus having other chips 'fit the hole' guess the thing to do with sockets is to just order a lifetime supply of 100k pieces at a time so at least they are all exactly the same model and tint of black and not 4 different types mixed up. just dipping the whole contraption into an epoxy mold would probably be better but take a bit too long to dry (24 to 60 hours) building towers of sockets with wires coming out the side however is not the proper way to do things.. so time to order the next batch of pcbs if this works. lol.

$FF40 obviously should be FF3F but anyway... that then feeds into the 74HC139

A certain company i once worked for would have fired me on the spot for even suggesting this pile of sockets with a 74HC00N literally glued to the top and melted together with an already heavily abused soldering iron, held in place by a rubber band. BUT IT FIXED THE PROBLEM.

now let's re-work that a little bit into the rev-b of the board. lol (and somehow patch up boards of the rev-a batch to permanently accomodate this extra logic with some actual wires and scratched away traces at the bottom) plenty of nand-gates to be used as inverters left in a 74hc00 to replace the 74hc04 and still keep the reset led (the RW led never did much of a useful job anyway other than being on at the same time as the power led and (appearantly) blinking at 2mhz or so, a bit too fast for me to notice

after a few vague 'new' errors such as '20 GOTO 10' would suddenly be a SYNTAX ERROR after that being an established part of the BASIC language for like what? 45 years now, which turned out to be a result of the thing wiggling out of it's socket all the time by itself it's currently busy peek() ing it's entire memory in a for loop, just a single peek or attempt to initialize an integer variable would have caused it to die before this modification lol. think imma leave that running like that for the rest of the night and see if any more weird crap pops up that needs addressing...

as it turns out backspace (as long as the 7F is translated to 08 and then translated back a bit to something a bit more complex than just 08 to actually also wipe out the character on a vt100 screen on the way back) even worked all along already too just that i never got to notice that as it was pooping out random errors the entire time

hmm. i did notice the thing happily inserting all kinds of illegal control characters both into code and into the screen earlier on. need to check if that bug is gone now too, and somehow fix it up to figure out it's entering code so that all gets upper cased all the time by itself (while turning that translation off during string entry)

hmm. it'll probably run any version of commodore basic now too. will insert one of the previous roms and test that too once it has shown to keep doing what it's currently doing for a few hours without randomly dying again

As you seem to be getting your system working now, here's an updated EhBasic version.... it's based on the latest patched version that Klaus has been maintaining. There are numerous changes however; removal of all the interrupt bits and pieces, reduced page zero usage, all page zero usage is now consecutive from $00 - $85, CMOS instructions/addressing modes used, etc. Also, it's one single assembler file... just change the vectors starting at line 7460 to reflect your monitor and you're done. Default assembly starts at $B000, which is also the cold start for EhBasic.

NOTE: startup message was removed as well as the RAM test... my Monitor calls either cold or warm start and announces the Basic version, then jumps to $B000. I've run this code on 2 different systems, i.e., different I/O but the same BIOS functions and no changes were needed, sans the vector addresses noted above.

WDC Tools are used for assemble/link, and can be downloaded for free.

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

c3rob, after you eventually got that computer up and running,
the question is if you want to make this a "stand allone" system.
Means attaching a keyboard and a display to it.

A simple approach for adding a PS/2 keyboard from Lee Davison is here,
but reading the keyboard output Bitwise would take up some CPU time...

My approach was to use two 74164 shift registers for sampling the Bits from the keyboard,
then to check with a monoflop for the end of the transmission for latching the data from the keyboard into a 74574 latch
which passes on the data to a 6522 I\O port. (Had no 74595 in the drawer).



Edit: of course, you also could use an old Commodore keyboard... or build something like a Commodore keyboard.

;---

On the same page, there is D04, my CRT\LCD controller.
It passively snoops the 6502 bus for write cycles to $0400..$7FFF, then mirrors them into the on_board display RAM.
When building it, I didn't know as much about the 6502 bus timing as I know now,
and maybe it would be better to use 74377 latches for fetching address and data from the 6502 bus.



There were a lot of other approaches for generating a video signal in the forum:
CPLDs, microcontrollers, etc.

;---

Another interesting question when trying to build a secure system is, what to use for mass storage.

Hard disks probably shouldn't be trusted too much:
For installing a hidden Linux Kernal inside a hard disk controller, see here.

USB sticks usually contain a microcontroller plus a lot of "flash memory".
IIRC some years ago the German computer magazine c't had success in building a virus aiming at the microcontroller in some of those USB sticks.

I'm not sure about SD cards etc., if somebody has detailed X-ray pictures of SD cards post a link here.

Don't feel too safe on the 6502 though, I remember to have had a killer virus back in 1987 which ran resident in the 1541 RAM...

A small LCD text display might be good for displaying "status messages" of the computer.

When using the display in write_only mode only, it would be possible to reduce the amount of 6522 I\O pins required by using shift registers.

I did that a few years ago when I made an LCD test fixture. Over the years, I had tested so many different brands of intelligent character LCDs, and although they all use the same instruction sets, their pins were arranged different ways, so I wanted something that could accommodate new ones more easily, using jumper selections. The occasion this time was that someone here on the forum wanted me to test a very large 16-character LCD he sent me that could be read across the room. For the electronic part, I used a 74HC595 shift register connected to the serial port of one of the workbench computer's VIAs by only three lines, data, clock, and strobe. The 595's Q0 output went to the LCD's E (enable) input, Q1 went to the RS (register select) input, and Q4 through Q7 went to the LCD's D4 through D7 (doing a 4-bit interface). The LCD's R/W\ line was grounded.

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

need to sort out some stuff and start pushing it onto github.

todo: cs8900a boards (olimex no longer makes them (not even the 3v crap anymore - let alone the 5v ones) so we'll have to get them assembled by the pcb factory itself i guess

a 1602A lcd display is under consideration as a standard part of it, driven by some 74HC377 octal latch (which can basically just use the -entire- rom address space when write is low)... but it's datasheet mentions timing that would be more acceptable for a 200khz bus than for something like this. lol. with some operations taking -milliseconds-. having to 'wait for chips to finish operations' in software and other inconsistencies in the memory map are not clean design... the lcd display slurping up the i/o pins of half a via is also a bit of a waste as it's pretty much a write only thing anyway.

hooking up local keyboards also requires local video. the keyboard is the easy part. finding 5v dip videochips nowadays.. (yeah, well, nintendo ppa clones. THOSE, you can buy by the bucketload (but only do 32 char wide displays all nice and well for supermario but not so well to just display text (if it even does that by itself in the first place .. pff lol.

there are however some 'open source' single-pic-based vt100 terminal boards which can obviously just get screwed into vesa mount boxes to put on the back of monitors.

currently the firmware has ehbasic in it which seems to fully work except for load/save due to not having decided on the disk local bus and protocol, and the ethernet version of that yet. still needs a decent monitor with single stepping and full assembly/disassembly.

ethernet comes first. then sorting out the rest. (also probably solves the 'disk protocol' problem as the moment it talks netware core protocol or nfs (not advisable as it uses sector addressing and requires ip overhead) or smb or something new along those lines, it actually no longer needs local disks now does it, we can just put all of that, in seperate boxes, along with the ssds