Two of these: https://tinyurl.com/tzh9t26

One for +/- 5V and one for +/- 12V

Or you could use one for the above for the 5V rails and one of these: https://tinyurl.com/s8qkou6

To generate the 12V rails.

Small, cheap, effective. I've used both and they work great.

_________________
Bill

While I hate to disrupt your minimal system idea, I cast my mind back to early 1975....

1K is a pretty healthy amount of RAM for a system and the ability to expand to 2K makes it even luxurious. But since you've got serial I/O, and not just a front panel, I might just go all the way to truly deluxe and rework it to allow 4K of RAM. Because I hear some guy is working on a high-level language, but it will require 4K to run.

_________________
Curt J. Sampson - github.com/0cjs

I'm not even sure what I'll do with that entire 2k, but if I did want to get BASIC running I'd need at least 4k for the BASIC interpreter (Tiny BASIC, integer only and quite limited) and then at least another 1k for basic programs. I'm not sure that would fit in the 8k range I have with the current address map limitations. There'd be an interesting challenge there and it certainly would be a near minimal BASIC computer, so maybe worth considering.

I think that the better thing to do is make this thing a period accurate recreation of the TIM, and then build another board using the 6532 and probably a full 6502, 8k RAM chip, 8k ROM or even 2. Be nice if I could make it CMOS, but I don't think you can find CMOS 6532's, I guess you'd just use a 65C22, and by then it's just a standard small 65C02 SBC.

Oh! I had a brain fart there: the original Micro Soft BASIC did in 4K RAM-only system with a little bit of room for your program, but that was for an 8080, not a 6502. Still, I'd bet one could fit a less limited language than Tiny BASIC into 4 KB with space for a not completely trivial program as well, though I suppose it's incumbent on me to prove that claim. :-)

_________________
Curt J. Sampson - github.com/0cjs

Tom Pitman's Tiny BASIC will fit into 2K, but just. You won't even have room left over for a serial comm monitor.

It's small and simple and can be used as a procedural control language to call ML subroutines. Then use what's left of your 4K ROM to add routines you can call from TB to get the real work done. Iv'e done this in the past. Saves burning ROMs for every little change in your program flow or logic.

_________________
Bill

It’s good to know that you can fit a basic in 2k, I thought 4k was the minimum. It would be a worthwhile goal to get it working.

The TIM schematic is very simple, that’s part of the appeal, and I was impressed that it only used a 7400 and 7404 for the address decoding (not that there is much to decode as some of it is done internally in the 6530). I’ve been sidetracked over the last few days understanding it and modifying it to work with my reduced address bus. What I discovered is that, as with any minimal addressing scheme, the addresses are aliased all over the place. Things are decoded in the right locations, but also in many other ones too. That’s not an issue for a closed system, but if I have an expansion bus as planned I need some free address ranges, and with only 8k total, I need a lot of that to be free. Finding 2k for BASIC should be do-able, but a single 4k range is probably not.

Something else I thought of, with the expansion connector, there could be a BASIC card with the BASIC ROM on it.

Update: Looks like Tiny BASIC is 2220 bytes long, just a touch too big to fit in a 2k ROM. That’s for the KIM version so should be about the same for TIM.

When reading up on Tangerine computers a while back, I noticed they had an interesting way of handling addressing for their Mircotan 65 single-board computer. When operated as a single board, the built-in monitor called one of its own subroutines using an aliased address. When fitted with a TANEX expansion board (and the modification of a few links) that address was now decoded to an improved monitor on the expansion board, without having to modify the ROM on the core Microtan board at all. I'm a little hazy on the details, but I think some of the address decoding was handed over to the expansion board when fitted.

Perhaps there might be some inspiration to take from this for your design?

So the address decoding gets really complex when you move from a 6502 to 6504/7. So much so that it'd just be a lot easier to use a 6502. But this is a competition that requires the use of a smaller 6502, so I need to figure this out. I've spent more time on it than I'd like to admit, it's one of those problems that I think are unique enough that there isn't a simple algorithm for solving.

The core of the problem is that the 6530 has a really nice address decoder built in, which can be configured just like the internal ROM. So in theory you could set this up and avoid adding much external logic. But we have a pre-configured 6530, which already has the address decode set, and set up for a 64k address space. The chip select equations look like this:

ROM = RS.CS1.CS2
RAM = RS./CS1.CS2.A9.A8.A7.A6
I/O = /RS.CS1.CS2.A9./A8./A7./A6

And a standard TIM would be configured like this:

RS = A12
CS2 = A13
CS1 = /(/PB4.A15)

Which gives an address map looking like this:

2200: Start IO
223f: END IO
2600: Start IO
263f: END IO
2a00: Start IO
2a3f: END IO
2e00: Start IO
2e3f: END IO
3000: Start ROM
3fff: END ROM
6200: Start IO
623f: END IO
6600: Start IO
663f: END IO
6a00: Start IO
6a3f: END IO
6e00: Start IO
6e3f: END IO
7000: Start ROM
7fff: END ROM
b3c0: Start RAM
b3ff: END RAM
b7c0: Start RAM
b7ff: END RAM
bbc0: Start RAM
bbff: END RAM
bfc0: Start RAM
bfff: END RAM
f3c0: Start RAM
f3ff: END RAM
f7c0: Start RAM
f7ff: END RAM
fbc0: Start RAM
fbff: END RAM
ffc0: Start RAM

Lots of aliased locations, which wastes quite a bit of the address map, but everything ends up in the right place.

The best I've come up with so far is these equations:

rs = a12
cs1 = (/a12.a11.a10) | (a12./a11./a10);
cs2 = true

Which is quite complex for cs1 and wastes cs2, so it seems I should be able to do better. That gives this memory map:

000: Start EXP_RAM
07ff: END EXP_RAM
0e00: Start IO
0e3f: END IO
1000: Start ROM
13ff: END ROM
17c0: Start RAM
17ff: END RAM
1bc0: Start RAM
1bff: END RAM
1fc0: Start RAM

Which is not too bad. It's a little complex and the TIM RAM is is in two locations that it doesn't need to be, but it would work. 3 NOT's, 2 3 input AND's, and an OR gate. Actually, now that I've sketched it out, the propagation delay would be pretty bad, so maybe this wouldn't work.

So a TIM system with a 6504 looks like it would be quite hard to build.

If you're just looking for an integrated programming environment with a command line, interpreter and program editor, VTL02C fits in 1K of ROM with room to spare, and only uses NMOS instructions. If you remove some of the "enhanced features", you could probably fit your character I/O routines inside the same 1K. VTL02C keeps its 128 bytes of variables in zero page, and needs roughly equal amounts of stack space and input buffer space too, though. If you keep your variable usage under scrutiny and don't approach the "maximum" 128 columns for the command line, you should be able to get a small interactive system running with very minimal resources.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

(I think the key to simple address decoding is not to worry at all about aliased locations. It's not a problem for the software, or the hardware, merely something for the human to deal with.)

Indeed, and the lack of A13/14/15 on the 6507 or 6504 means that the entire 8K external address space is aliased eight times as seen by the CPU inside, anyway. The important thing is that software accesses particular addresses and finds the correct hardware there.

Is there a bunch of legacy software for the TIM that has to be accommodated?

No, it’s just that with only 8k of address range I don’t think I can waste much of it on aliased addresses. Part of the challenge I guess.

There’s no real legacy software that I know of, and this 8k address range is really limiting, I guess people that bought the TIM kit would have used it as a cheap development system or for some automation type project, but they’d normally pair it with a full 6502 so would have more room for expansion. The real advantage of the TIM is that you don’t need a development system or an EPROM programmer to get started. But you would need a terminal.

There will be none wasted in the aliasing. You should get the whole 8K for use. It will just be that 8 different addresses will point to the same place in memory, or if you prefer each byte of memory will have 8 different addresses.

For instance, you will be able to read or write to $0000 by accessing $0000, $2000, $4000, $6000, $8000, $A000, $C000, and $E000.

_________________
Bill

I may be missing something here, but you are going through quite the exercise of using a 6532 to decode the memory map, isn't one of the issues up front that you can't get a 6532 and are using the contest supplied 6530 instead?

It seems that leaves you to design a memory map decoder not restricted by the 6532 at all.

Okay, here's my suggestion:

Start with a '138 on A10/11/12. The bottom two outputs of this are /CS lines for two 1K RAM banks, let's call them /CSR0 and /CSR1. Wire the ten remaining address lines direct to both the RAM and the 6530.

Generate the 6530's CS2 as ~(/CSR0 & /CSR1), and wire A12 to the 6530's RS input. Every access that is not to RAM will now go to some part of the 6530, with the I/O appearing at $6E00 (and $0E00) as required.

Finally, call the top output of the '138 /VP, and generate the CS1 input as (/VP | PB4). This allows the vector table to be remapped from ROM to the 6530's internal RAM as in the original.

The above assumes you actually have a 6530-004, and not an ersatz 6530 built from a 6532 and a ROM. The setup will be different in the latter case. Assuming you have a modest clock speed (1MHz or less would be typical for the TIM era), you shouldn't need to worry about propagation delays.