That's why I'm including the 3.3k resistor in the line, so it will limit current sinking into RDY from external devices if WAI is executed. Will this work?

OK. I missed that, sorry... I thought the green wire was going to 0v. I don't have any suggestions for your wait state stuff though I solved it in my system by not having a requirement for any.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

You're running (E)EPROMless right? I seem to remember you telling me that and yours is on the pretty red board. I would like to not have wait states, but I do want to include the EEPROM, as the tradeoff seems worth it imo for having the computer situated as it is.

Yes, ROMless here. Not sure about pretty, but it's a start!

I really ought to say almost ROMless - the ATmega has 128KB of Flash which currently holds Applesoft, EhBASIC, BBC Basic3, and some other stuff I'm working on..

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Right, I may have to make an atmega based board sometime, would be way simpler/cheaper, just doesn't seem quite as fun to me as handling everything with discrete logic

I have a GAL 22v10 on mine. Saved me mucking about with a small raft of TTL.

I did start with the whole "retro" idea when I made my little SBC - wanted a classic memory mapped video system, old style UARTs, and whatnot, however as I started researching chip availability I sort of decided that to go down that route may be somewhat challenging - especially when I had initially set 8Mhz as my target speed, so I figured 1982 might be a good date - (When the BBC Micro came out) at that point we had ULAs and early PALs - the ATmega is my ULA - actually more as it now incorporates a disk controller, and the GAL is just a PAL to save me 3 or 4 TTL chips on the decoding and interfacing side of things.

So hat's off for trying to stay very old-school!

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Thanks, although the audio/video generation that are planned are currently very *not* old school, due to chip availability. I don't think many VICs exist anymore like you find on the C64, so I'm planning to opt with the VLSI chip, the vs23s010, which is addressable over SPI and creates composite signals off its internal sram. Someone recommended it to me in my other thread, may've even been you, I can't remember now. For audio, I'm going with another VLSI chip, the VS1000, which plays ogg files. I'll have to figure out getting ogg files on and off the thing (since I don't have a file system planned currently) but other than that it seems pretty turn-key. For actual audio syntesis I have a daugher board planned that will do midi in and out, and also be able to synthesize some basic wave forms (maybe complex ones too, we shall see).

Speaking of daughter boards, I had an idea for another one earlier, and, I'll either start a new thread or put this in my old one probably, since it doesn't really belong in this thread, but being a cool idea, I just have to write it down here.

I've been considering creating a daughter board to handle some "ISA" extensions that exist in x86. Basically, it would be a massive ALU built out of logic chips. The idea is to use multiple 8 bit latches to form the entire width of it (for 256 and 512 bit math), and an 8 bit latch for the instruction to run. If I wire it right, it could be set up in such a way that the arithmetic logic would always be on, meaning you feed it an instruction, and then feed it data, byte by byte, and by the time you're done, it already has the answer, since the prop delays start as soon as it has data in the latches.

I think it's the coolest thing I've thought of yet, and maybe someone else has already thought of it and done it, but it seems like an easy way to allow the 65xx, with its modest 8 bit bus, handle large width machine words like 256 and 512 bit instructions do on modern x86 CPUs.

Sounds interesting, but if I may give you some advice; Draw a line under your design now and concentrate on finishing it and start writing code on it first... Seems obvious, but it will give you a good base to start on. I remember your original target date was ... tomorrow

Which is what I'm doing, even though I've been using the 6502 for a little over 40 years now.... It's nice to get back into coding on a limited platform, although I have the luxury of writing the ATmega side in C, I still have to write a lot of 6502 code to talk to it. And on 'wide' math, I recently had to write a storage allocator (malloc/free if you like), that's a lot of 16-bit manipulation and fortunately I remembered a nice little 16-bit pseudo machine called Sweet-16... So don't forget you can do stuff in software as well as hardware - the trade-off is speed, but sometimes the ease of doing it that way far outweighs the hassle of more hardware.

Also, having had my board working for some time, has allowed me to plan a little project roadmap, as it were and I now know what my next board will be and how I'll implement nice colour video and sound and jump my 1982 start date (BBC Micro) to 1986 (Apple //gs) but that board will use the same ATmega IO processor, so I'll have a ROM loader, serial IO and a filing system from the word go. (and I can test the video & sound on the 6502 board too)

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Oh ya, that's why I say this idea is for a daughterboard, not something I'll be building now (although I might pick away at a schematic in my free time, it's just too tantalizing not to look into). Also, the video and audio...I've set up sockets for them to go into on the board, the sockets are mostly SPI based, but each has 4 GPIO lines from a via to help things out. The VLSI chips are what I'm planning on, but anything that can be done with SPI will work on it too. The base design will just have a simple text display.

I will need to put one of my arduinos on a breadboard to program the EEPROM though, I've been considering looking for a shield that may help with this, but it should be easy enough to bit bang data into it on a breadboard, and save the money.

So, I found something interesting for variable clock generation, I wasn't looking for it at all (was researching CPLDs) but this came up, and it looks pretty useful.

This may be a better option than my 1699 + digital pot setup, I'm not sure yet, a cursory glance tells me it is though

(That is, Dallas/Maxim DS1085 EconOscillator Frequency Synthesizer. Indeed it looks quite flexible and quite applicable, including frequency changes on the fly.)

Sorry for not stating the name, should probably protect against links dying.

This chip looks cool enough....I might just rip up my current design and use it, if it turns out to be workable.

I found it while reading this hackaday article on working with CPLDs. They use it for clock generation on their board, so it seems very much usable for this type of thing.

Speaking of CPLDs, this is off topic, but I think worth noting, I'm not sure when Daryl will have a replacement for his 65SPI, but I may start working on a pin compatible replacement myself as a pet project. I've found this Atmel ATF1502AS CPLD ina PLCC-44 package that looks like it may work to be a drop in replacement. Unfortunately Xillinx does not appear to offer any CPLDs in PLCC 44 anymore.

EDIT: the above CPLD cannot be pin compatible, it has mismatched GND and VCC pins.

You might also be interested in this topic about wait-stating, especially with regard to the 65C816.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I recommend the ATF1504AS. Same package size but more logic resources.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I'm actually looking at a slightly larger one, and taking up an idea garth gave me over email, to make a chip that can emulate a VIA, a UART, SPI, and I2C (and I'll probably throw in WSG and possibly some decoding, since the chip has a bunch of extra pins). The model isATF1508AS-7