65XX SBC general help and color display help needed

[GARTHWILSON]

It would be a lot of board real estate if you were to put an extra 6522 on just to get the watchdog timer. I'm sure the other features on the '22 will help it pay for itself nicely though. It's hard to have too many.

[backspace119]

GARTHWILSON wrote:

It would be a lot of board real estate if you were to put an extra 6522 on just to get the watchdog timer. I'm sure the other features on the '22 will help it pay for itself nicely though. It's hard to have too many.

Ya I wanted to have at least one via, possibly 2, been taking some notes from your workbench computer and trying to expand it a bit. I'm also looking at grant Searles ps/2 circuit right now (his monitor circuit is a bit too much I believe, I'd rather not use a atmega mcu if I don't have to) I'm thinking about getting a parallel interfaced text display and throwing it behind one of the vias.

[drogon]

backspace119 wrote:

Ya I wanted to have at least one via, possibly 2, been taking some notes from your workbench computer and trying to expand it a bit. I'm also looking at grant Searles ps/2 circuit right now (his monitor circuit is a bit too much I believe, I'd rather not use a atmega mcu if I don't have to) I'm thinking about getting a parallel interfaced text display and throwing it behind one of the vias.

It's very refreshing to read all this - lots of enthusiasm, a busy thread with lots of great ideas and thoughts from others too which I'm sure will benefit the community, but I wonder about your project - go back and re-read your first post (I just have) to remind yourself of your aims - and timescales - your poor partner is going to get a self-assembly kit at this rate

Cheers,

-Gordon

[backspace119]

drogon wrote:

backspace119 wrote:

Ya I wanted to have at least one via, possibly 2, been taking some notes from your workbench computer and trying to expand it a bit. I'm also looking at grant Searles ps/2 circuit right now (his monitor circuit is a bit too much I believe, I'd rather not use a atmega mcu if I don't have to) I'm thinking about getting a parallel interfaced text display and throwing it behind one of the vias.

It's very refreshing to read all this - lots of enthusiasm, a busy thread with lots of great ideas and thoughts from others too which I'm sure will benefit the community, but I wonder about your project - go back and re-read your first post (I just have) to remind yourself of your aims - and timescales - your poor partner is going to get a self-assembly kit at this rate

Cheers,

-Gordon

Honestly, she might like that better (except she's gotten bit sick of soldering recently since she's doing a lot of it for her EE degree). I have a backup gift planned (engraving a nice plank of hardwood on my CNC) and this may end up being a gift for our anniversary (March 25th, so an extra month and a half). I want the first iteration to be capable, and hopefully expandable so I can add a video card, and not have to build another.

At any rate, I've been learning a lot and I think my fiance's already guessed at what I'm building her (or at least partially guessed) and I think she knows it's a big project too.

I do want to hit my original goal here, and maybe a little more, someone mentioned cartridges with careful mechanical design earlier and since then it's been a bug in my brain that won't leave, I think that by the end this will hopefully be a really cool project capable of playing some cool classic 2d color games. (I'm going to crack open solid works probably tomorrow and start laying out the case I'm going to 3d print for it, so I can get an idea of space constraints)

[drogon]

backspace119 wrote:

I do want to hit my original goal here, and maybe a little more, someone mentioned cartridges with careful mechanical design earlier and since then it's been a bug in my brain that won't leave, I think that by the end this will hopefully be a really cool project capable of playing some cool classic 2d color games. (I'm going to crack open solid works probably tomorrow and start laying out the case I'm going to 3d print for it, so I can get an idea of space constraints)

On cartridges... So way back, just over 40 years for me now, the Apple II was my first proper computer - no cartridges there, we had these big thin flexible things called floppy discs (or disks if you like)

My first cartridge experience was the Atari 2600.

Some time later the BBC Micro (no real cartridge facility, but something else), then the BBC Master - with slots for 2 cartridges, but we're now in the mid 80's.

Cartridges were really for games (which is part of your aim), but some came with more than just ROM - extra RAM and (I think in some cases) NVRAM for longer term game score storage.

The BBC Micro (and Master, etc.) had "sideways" ROMs - essentially ROMs all occupying the same (16K) address space switched in and managed by the operating system. Not too shabby for a system in 1982, but the PCBs were fairly big...

I'm thinking/pondering that if you do go down the cartridge route, then make the interface a bit more detailed, so the cartridges can add extra functionality - but then you end up with a processor bus (containing some/all the address + data lines, clock, r/w, etc.) rather than a peripheral bus, and do read thoughts here and elsewhere about processor vs. peripheral buses.

My little SBC has an SD card connected to the ATmega and the more I use it and think about it, the more I feel I've just designed a BBC Micro with the host (the BBC Micro part) being the ATmega - that does the screen, keyboard, disk (SD) and talks to the 2nd processor (the 6502) via a tube-like interface. It even runs BBC BASIC and I could probably make it run most standard BBC ROMs if I could be bothered... I never set out to make it like that, but there's only so many variants... e.g. an early plan I had was for 2 x 6522's, one being a 16-bit peripheral bus rather than try to extend a 14Mhz processor bus. (and slow-down my 6502 with wait states to slow the bus down? never!)

You might also want to look at the RC2014 project for some other bus/cartridge ideas too..

Cheers,

-Gordon

[backspace119]

drogon wrote:

backspace119 wrote:

I do want to hit my original goal here, and maybe a little more, someone mentioned cartridges with careful mechanical design earlier and since then it's been a bug in my brain that won't leave, I think that by the end this will hopefully be a really cool project capable of playing some cool classic 2d color games. (I'm going to crack open solid works probably tomorrow and start laying out the case I'm going to 3d print for it, so I can get an idea of space constraints)

On cartridges... So way back, just over 40 years for me now, the Apple II was my first proper computer - no cartridges there, we had these big thin flexible things called floppy discs (or disks if you like)

My first cartridge experience was the Atari 2600.

Some time later the BBC Micro (no real cartridge facility, but something else), then the BBC Master - with slots for 2 cartridges, but we're now in the mid 80's.

Cartridges were really for games (which is part of your aim), but some came with more than just ROM - extra RAM and (I think in some cases) NVRAM for longer term game score storage.

The BBC Micro (and Master, etc.) had "sideways" ROMs - essentially ROMs all occupying the same (16K) address space switched in and managed by the operating system. Not too shabby for a system in 1982, but the PCBs were fairly big...

I'm thinking/pondering that if you do go down the cartridge route, then make the interface a bit more detailed, so the cartridges can add extra functionality - but then you end up with a processor bus (containing some/all the address + data lines, clock, r/w, etc.) rather than a peripheral bus, and do read thoughts here and elsewhere about processor vs. peripheral buses.

My little SBC has an SD card connected to the ATmega and the more I use it and think about it, the more I feel I've just designed a BBC Micro with the host (the BBC Micro part) being the ATmega - that does the screen, keyboard, disk (SD) and talks to the 2nd processor (the 6502) via a tube-like interface. It even runs BBC BASIC and I could probably make it run most standard BBC ROMs if I could be bothered... I never set out to make it like that, but there's only so many variants... e.g. an early plan I had was for 2 x 6522's, one being a 16-bit peripheral bus rather than try to extend a 14Mhz processor bus. (and slow-down my 6502 with wait states to slow the bus down? never!)

You might also want to look at the RC2014 project for some other bus/cartridge ideas too..

Cheers,

-Gordon

I really liked the floppies for the PC Jr. and cartridges have always been cool to me as well.

I knew about extending the capabilities on cartridges too, I actually was just talking to my brother about that tonight. We were both remembering the n64 and majoras mask, which required a memory expansion to run properly.

The nvram thing is something haven't thought about, but a cartridge with eeprom and nvram is easy enough, I may end up doing some other stuff on cartridges that need more power (although I really would rather refrain from putting processor busses off the main board).

As a note, I have some spotty info about older systems, a few of them I know inside and out, some I am clueless, I didn't know about the BBC micro until I started reading about it here.

[Arlet]

With RAM being fast and cheap, it may be a good idea to put a nice amount of RAM in the base system, and then make a cartridge based around a small serial flash chip. When the cartridge is detected, copy contents to RAM and then run it from there.

[BigEd]

I quite like that! Only a few pins too. (I had previously been thinking that a cartridge port can be anything between a ROM socket, which then needs lots of cleverness to host RAM or peripherals, and a full-ish system bus, which makes the host system into a bit more of a slot-based system which takes cards, much like the PC or the RC2014.)

[drogon]

backspace119 wrote:

As a note, I have some spotty info about older systems, a few of them I know inside and out, some I am clueless, I didn't know about the BBC micro until I started reading about it here.

Well... As the name implys, it's British. And so being British, while being full of technical boffinry, it suffered from our usual lack of marketing ability.

It was designed by Acorn for in conjunction with a BBC TV series aimed at improving computing education in schools and at home. Schools bought them by the van load - mostly because you could get 4 BBC Micros for the cost of an Apple II (which was already 4 years old by the time the BBC Micro was released). 2Mhz 6502, Better/Faster BASIC, expansion buses rather than slots, an operating system rather than a "monitor", networking (Econet; optional extra) and disk interface (also optional). It did have a highish speed cassette tape interface which was reliable though. I could go on, but there's loads online about it. I owned one at the time (and several now) One of the key interfaces was the "Tube" - a 2Mhz bus used for connecting a 2nd processor - 65c102, Z80, and a couple of others. Lookup the PiTube Direct project for a Pi project that emulates all of them - and more... In that scenario, the BBC Micro was the smart terminal providing screen/keyboard, disk, network, etc. to the Tube processor.

There were popular, but home users were faced with the Sinclair Spectrum (Z80 based) which was much cheaper, so more popular. the C64 didn't come to the UK until slightly later, but was popular too, but I think it was more popular in the US than anything else at the time (for home users)

If you want an amusing and slightly accurate documentary on the subject of its design, lookup "Micro Men", or: https://www.youtube.com/watch?v=XXBxV6-zamM

-Gordon

[DerTrueForce]

On the ACIA you mentioned, I really wouldn't use that part.
It's somewhat infamous around here for having a bug in it that makes it (in my opinion) very onerous to use. More info here: WDC 65C51 chips defective and here: UARTs: REPLACING THE 65C51.

I settled on the 28L92 for my design. It's easy enough to adapt to the 6502 bus. Mind you, there is nothing stopping you using the 6551 ACIA if you so desire.

On the subject of cartridges, I would use some kind of serial interface. The cartridges are made smaller, and multiple devices can still be packed into the one cartridge. SPI-10 might be a good starting point for the connector, although you may wish to add some extra select lines for extra devices, if that is something you think you might do.

[BigEd]

I've just updated a related thread:

• Acorn's BBC micro - some resources

(Not intending to monopolise information and opinions on the remarkable machine!)

[whartung]

Watch dog timers are more for machines locked in boxes that are stuck on poles out 50 miles from anyplace.

Everyone else uses a reset button to reboot the machine when they think it needs to be done, rather than waiting for, or simply racing, a watchdog timer.

Naturally, in theory, you can always reset or disable your timer, but if you think about consumer computers, I can't think of any of them that has some kind of first class watchdog timer capability. At best you have machines that will reboot when power is lost.

(Naturally, there are "soft" watchdog timers, where someone installs a program that looks for events and if it does not see them, it performs some action -- but that's different.)

[BigEd]

(Watchdog timers were also often seen in arcade machines. They are not isolated from people, but they are distant from technical intervention. A watchdog timer can counteract some classes of attacks on the machine, and make certain bugs less inconvenient.)

[BigDumbDinosaur]

backspace119 wrote:

After studying the circuit in the docs, I've been looking at these two parts here and here

One's an AHCT 245 and the other is a ACT 573 (non inverting).

A minor correction on what DerTrueForce said. If you use Garth's SIMM you will be working with SRAM that generates TTL-level outputs. Therefore, your bus driver should be a 74ACT245 or 74AHCT245 (note that the 74ACT245 is slightly faster than the AHCT equivalent, which isn't necessarily a good thing). The bank bits latch should be a 74AC573, as TTL-compatible inputs are neither necessary or desirable.

Quote:

I'm working out the logic on it right now, I think I need the non inverting 573, but there's an inverting one too, so I'm working on figuring that part out since it doesn't mention it in the docs.

You're thinking of the 74AC563, whose Qs are the complements of the matching Ds.

Quote:

Is there another part to this equation to make sure there's not bus contention?

If you correctly generate your /OE and /WE signals you should not see bus contention. Here's an example of a circuit for generating said signals.

Read/Write Generator Circuit

The above circuit is what I use in my POC units. /OE and /WD cannot go low until after the rise of Ø2 (PHI2), at which time the '816 will cease driving bank bits onto D0-D7 and will switch to data mode. The prop delay in the above logic, added to the time required for the addressed device to respond to /OE or /WE will give the '816 some turn-around headroom. Understand that the state of RWB will have been set by the MPU before Ø2 goes high, so the time from the rise of Ø2 to when /OE or /WE will be driven low will be the prop time of the 74AC00, typically around 4-5 nanoseconds on 5 volts. If you want to increase that lag you could use the 74HC00, whose tPD averages around 8-9 ns on 5 volts. Incidentally, it may come as a surprise to learn that the timing of /OE and /WE is not critical. As long as these signals are generated soon enough to meet the requirements of the slowest device at the highest Ø2 rate you plan to use it will all work.

Incidentally, if you use any 65xx I/O silicon, such as the 65C22, be aware that all control inputs must be set up before the rise of Ø2. These devices "understand" the 6502 bus cycle and will not attempt to get on the data bus while Ø2 is low. If you don't observe this requirement the device will not work.

Lastly, be aware of the 65C816's VDA and VPA outputs. At certain times during an instruction cycle the address bus could be in an indeterminate state. In some cases, that can result in improper selection and addressing of devices, which may cause some devices to malfunction. The NXP 26, 26C and 28L (mentioned below) series of UARTs is are such examples, the NCR/AMD/Buslogic 53CF94 SCSI controller is another one...

The general rule is if the expression VDA || VPA is false (|| meaning logical OR) the address bus may be in an indeterminate state and no chip selects should be generated. This can happen during Ø2 high and may result in the '816 "touching" something it shouldn't.

<Cue a comment from Ed about VDA and VPA not being necessary. >

Quote:

I definitely want some io, planning on an acia...

DerTrueForce wrote:

On the ACIA you mentioned, I really wouldn't use that part...More info here: WDC 65C51 chips defective and here: UARTs: REPLACING THE 65C51.

I also recommend you stay away from the 65C51. Aside from it basically being a primitive 1970s vintage UART, it has a pernicious (in the archaic sense) hardware bug that prevents the use of PIO or IRQ-driven transmission. It's quite clear from recent revisions to the 65C51 data sheet that WDC has no plans to fix this part. If you use something like an NXP 28L92, as DerTrueForce suggested, you will get two high speed TIA-232 channels in one package, plus some programmable input and output pins, and as a bonus, a precision counter/timer (C/T) that has sub-microsecond resolution. My POC V1.1 unit uses the 28L92's C/T to generate a 100 Hz jiffy IRQ that ultimately is the time base for a software uptime counter, software time-of-day "register" and a software delay timer function. See the below attached on how to interface the 28L92 to your 65C816 system.

28l92_interfacing.pdf

NXP 28L92 interfacing How-To

(381.39 KiB) Downloaded 167 times

The problem with using a VIA timer for system timekeeping is said timer is usually slaved to the Ø2 clock and therefore will change speed if the Ø2 rate is also changed. That would mean you'd have to make changes to your timekeeping code in order to maintain accuracy should you decide to change the Ø2 rate. That won't be the case with using the 28L92's C/T, as it can be driven by the 3.6864 MHz X1 clock used by the 'L92 to generate bit rates.

[Chromatix]

Hence my earlier recommendation to use a 28L92 to replace both the 6551 and 6522.