8 bit computer without RAM

[Pjotr]

My particular troubles with the zx spectrum (+2), is the I/O decoding. I couldn't really find an empty I/O address, and the ones I tried didn't work.

Can't remember exactly how I did it 30 years ago but it shouldn't be a problem. Controlled whole array's of LED's, AD and DA converters with it. If you search the net for "zx spectrum i/o map" I am sure something useful will come up.

Hé, you could hook up a printer, extra RS232 ports and a fantastic "Super tape drive" (that only worked a few times ) from Sinclair itself to the extension connector.

[SeanB]

How about the 8155 RIOT? 256 bytes of ram, some IO and a timer, and you can interface it almost directly to the Z80.

[T3sl4co1l]

Learning?

Start with AVR.  No contest.

It's available, it's common, it's well documented (if not always by the manufacturer... but Atmel is no Microchip, let's just say that!), and it's easy to learn (nearly orthogonal -- i.e., instructions with a given input/output mode, follow the same scoping (reg/imm/mem) rules, for the most part), and it's practical (AVR is current gen, if not the most popular perhaps?).

Z80 I'd say is a close second, because it's also easy to use, but has the advantage of being more user-friendly: the instructions do more.  AVR is RISC style (load-store architecture), meaning to do the least of almost any elementary operation takes three instructions or so.  Z80 has some of that as well, but it's more powerful.  And also slower (the original being 3-4 clock cycles per instruction cycle, with the longest instructions taking several instruction cycles to complete).

BTW, I think eZ80 is different, so don't dive into that, expecting classic Z80.

Once you know an instruction set, you can move on to heavier and more thoroughly demented things, like x86... Doing DOS programs in MASM is pretty easy, but you most likely will not be doing full Windows applications with 32 bit instructions (or 64, for that matter), and floating point and SIMD extensions.  At best, those should be left to the core inner loops, with a good trusted compiler filling in everything around.  And anyway, almost all things done on that serious of a level, are done relatively quickly -- the CPU operates on what data it has available locally (top level caches), then finishes, waiting for more data from the lower level caches.  It's not so important to hand-optimize inner loops for this reason.  Optimization today is more about cache size and prediction, being able to get data to the CPU just as it needs it.  A poorly written algorithm can waste so much time if it's grabbing data randomly.  That, and multiprocessor design (using other CPU cores to share the effort, or doing it on the GPU for that matter).

Tim

[C]

My particular troubles with the zx spectrum (+2), is the I/O decoding. I couldn't really find an empty I/O address, and the ones I tried didn't work.

To cure this problem, do like others have done. Add a input to the expansion buss that will disable all on board decoding. One system went further and had a signal ON_Board_Decode, an OR of chip selects. Using this signal allowed non fighting add on boards.

An Intel development system back then used the following idea. On boot all memory reads came from rom/eprom and memory writes went to ram. The first stage of boot program was
1. Set HL register to FFFF
2. Jump if HL = 0
3. Read memory using HL as address.
4. Write memory using HL as address.
5. DEC HL
6. goto #2

A simple block copy of rom to ram starting at highest address. By going from high to low allowed adding unknown roms and allowed for roms that decoded to many address blocks.
Step#2 jumped to code that allowed patching rest of boot program, Adding more boot devices or init code.
The system when ready wrote FF to IO address FF which set a flip-flop changing read from rom to read from ram. It also removed flip-flop from IO space.
The developer using this system had a reset able ram based system.     

[ChristofferB]

How about the 8155 RIOT? 256 bytes of ram, some IO and a timer, and you can interface it almost directly to the Z80.

I completely forgot about that. that'd be a good low-chipcount compromize! Thanks!

My particular troubles with the zx spectrum (+2), is the I/O decoding. I couldn't really find an empty I/O address, and the ones I tried didn't work.

To cure this problem, do like others have done. Add a input to the expansion buss that will disable all on board decoding. One system went further and had a signal ON_Board_Decode, an OR of chip selects. Using this signal allowed non fighting add on boards.

An Intel development system back then used the following idea. On boot all memory reads came from rom/eprom and memory writes went to ram. The first stage of boot program was
1. Set HL register to FFFF
2. Jump if HL = 0
3. Read memory using HL as address.
4. Write memory using HL as address.
5. DEC HL
6. goto #2

A simple block copy of rom to ram starting at highest address. By going from high to low allowed adding unknown roms and allowed for roms that decoded to many address blocks.
Step#2 jumped to code that allowed patching rest of boot program, Adding more boot devices or init code.
The system when ready wrote FF to IO address FF which set a flip-flop changing read from rom to read from ram. It also removed flip-flop from IO space.
The developer using this system had a reset able ram based system.     

That's pretty darn smart.
I don't want to do a whole lot of work with my ZX spectrum at this point, since The cassette interface died on it, and I'm not at all long enough to make a custom ROM for it. so I can't really use it.

[C]

If I was building a Z80 today, I would not be thinking small ram or no ram. Huge static rams are not that expensive. You can connect rams greater then 64K to a Z80. Think cheap Huge that you can work with.

With access to any kind of mass storage you do not need much rom. My "Lobo Max80' could boot from floppys of almost any size and type & SCSI hard drive or network. The boot rom is 512 bytes. Back then almost any other choice for rom would have required adding a wait state for a slow rom.

Designers of Z80's often forget that a write can go to more then one place.
An example would be read from ram, write to ram & display ram. Saves time delay syncing with video ram for reads.
The Max80 used this idea to make working with bank switching ram easer, gaining speed at almost no hardware cost.

C

[Pjotr]

It's what your goals are. If it's just learning assembly coding, you can simply do with a small debug monitor rom or a bootstrap loader rom, 32K - 64K static ram chip, a serial interface peripheral chip and an address decoder. Develop your code on a PC or whatever and download it in the small Z80 system ram through the debug monitor rom / bootstrap loader and run it.

[ChristofferB]

It's what your goals are. If it's just learning assembly coding, you can simply do with a small debug monitor rom or a bootstrap loader rom, 32K - 64K static ram chip, a serial interface peripheral chip and an address decoder. Develop your code on a PC or whatever and download it in the small Z80 system ram through the debug monitor rom / bootstrap loader and run it.

That's the plan, more or less.

Okay, this is a rather different problem, though on the same project. I got the system I described together, and made a (very) small program to run from ROM.
basically puts some value in register A, outputs it, new value, loop. The output port is not decoded: it's just the IORQ and WRITE signals NANDed together to the CLK input on a 74LS374 that then outputs the data bus on some LEDS.

Clock is good, running 30 Hz for debug, memrq, addresses and data flickers as expected, but the /IORQ doesn't change, thus not latching. Here's the code, I'm hoping one of you could tell if this is a software thing or a wiring/damaged chip thing.

Code: [Select]

0001   0000             ;**************************************************************************
0002   0000             ;*                                                                        *
0003   0000             ;*                          WorkDammit-32 ROM V.1.0                       *                         
0004   0000             ;*                                                                        *
0005   0000             ;**************************************************************************
0006   0000             ;*     Very simple bit pattern output to port. As of now,                 *
0007   0000             ;*     system outputs on all ports simultaneous (no address)              *
0008   0000             ;*     To be run with very slow clock, no pauses!                         *
0009   0000             ;*                                                                        *
0010   0000             ;**************************************************************************
0011   0000             ;*                                                                        *
0012   0000             ;*                           Coded by Christoffer B                       *
0013   0000             ;*                                27-07-2015                              *
0014   0000             ;**************************************************************************
0015   0000             
0016   0000             .org 0000H   ;start at address 0000 in ROM
0017   0000 3E FF       TEST: LD A,00FFH     ; Load FF into register a, use sneaky 0's
0018   0002 D3 00        OUT (00H),A   ; output value of reg. a via port 00H
0019   0004             
0020   0004 3C          INC A      ;A++
0021   0005 D3 00        OUT (00H),A   ; output value of reg. a via port 00H
0022   0007 3C          INC A      ;A++
0023   0008 D3 00        OUT (00H),A   ; output value of reg. a via port 00H
0024   000A 3C          INC A      ;A++
0025   000B D3 00        OUT (00H),A   ; output value of reg. a via port 00H
0026   000D 3E 55        LD A,0055H     ; Load FF into register a, use sneaky 0's
0027   000F D3 00        OUT (00H),A   ; output value of reg. a via port 00H
0028   0011 3E AA        LD A,00AAH     ; Load FF into register a, use sneaky 0's
0029   0013 D3 00        OUT (00H),A   ; output value of reg. a via port 00H
0030   0015 C3 00 00    JP 0000H     ;infinite loop
0031   0018                         
0032   0018             .end ;this ends the program
tasm: Number of errors = 0

Thanks in advance!

[C]

IORQ is active low. Normally written as /IORQ
WR is active low.  Normally written as /WR

Your code should cause /IORQ  and /WR to pulse low at same time.
if not look for a short.

74LS374 CK pin needs a low to high change to latch data.

Note: For Z80 data is valid before both go low and stays valid for a short time when ether goes high.

A NAND gate would create a low to high change on output when /IORQ goes low or /WR goes low or both go low.
So a memory write would also create a low to high change.

A NOR gate would create a low to high change when both become low.

C

[ChristofferB]

IORQ is active low. Normally written as /IORQ
WR is active low.  Normally written as /WR

Your code should cause /IORQ  and /WR to pulse low at same time.
if not look for a short.

74LS374 CK pin needs a low to high change to latch data.

Note: For Z80 data is valid before both go low and stays valid for a short time when ether goes high.

A NAND gate would create a low to high change on output when /IORQ goes low or /WR goes low or both go low.
So a memory write would also create a low to high change.

A NOR gate would create a low to high change when both become low.

C

Sorry, should've clarified that; I wrote IORQ and WR because I inverted them, then fed them to a NAND gate, creating an OR gate. but yes, that should be a NOR.  That still doesn't explain the never-changing IORQ line. No shorts, /IORQ measures a couple of MOHM to both rails AND surrounding pins. hmm.

[C]

If you have nothing connected to /IORQ and it does not pulse low with that program then probably bad Z80

The first bad Z80 I came across cost $500 new with the replacement costing $350 and it was in a home built system.

When playing with electronics it is a good idea to add protection if you can.
To keep from blowing a Z80 you could use buffer chips to protect the Z80 from your play/debug.

C.

[ChristofferB]

Well on the bright side they aren't 500$ anymore  - Yeah, that's what I was afraid of. And in most books on microcomputer design, every data, address and control signal is buffered, of course that's the proper way of doing it.

[ChristofferB]

Nope, zx spectrum sais CPU is fine. damn.

[C]

 zx spectrum might not use any IO in the IO address space.
If it does then trace all connections to /IORQ pin,

Could you be putting to great of load on the /IORQ pin?
What all do you have connected to this pin?

C

[matseng]

In the old days, it wasn't uncommon to add more system RAM by piggy-packing and soldering the new chips onto the existing RAM chips and to wire the chip selects separately. It wasn't pretty, but it worked.

Yup, did that back in the late 1970s, if I remember correctly it was 2102 RAMs (1024x1 bit) that I piggybacked eight of in a stack and peeled out the data pin on each of them to get a 8 bit wide databus.  Compact and nice. :-)
 

[Pjotr]

Lots of info: http://www.z80.info/index.htm

There you will also find the romless method C described and a small Pascal program to get the code from PC into the Z80 system through the PC's parallel port.

[HKJ]

If you just want to play with z80 assembler, why build hardware when you can get z80 emulators for free?
There is a list on the z80 size: http://www.z80.info/z80emu.htm

[ChristofferB]

zx spectrum might not use any IO in the IO address space.
If it does then trace all connections to /IORQ pin,

Could you be putting to great of load on the /IORQ pin?
What all do you have connected to this pin?

C

Checked /IORQ with a scope and it flickers along happily. should be good.
And it's driving a single 74LS04 gate. Should be fine I think.

If you just want to play with z80 assembler, why build hardware when you can get z80 emulators for free?
There is a list on the z80 size: http://www.z80.info/z80emu.htm

That's true, but a bit like cheating!