-
Zilog only guaranteed that it would drive 2 LSTTL loads,
Z80 VOL <=0.4V @ 1.8mA, VOH >= 2.4V @ 250uA. LSTTL unit load is 400uA low and 20uA high, so it should be able to drive at least 4 LSTTL loads.
The NSC800 is rated for <=0.4V at 2mA and >=2.4V at 1mA, so it should be able to drive at least 5 LSTTL loads.
However I would avoid LSTTL if possible, for versatility and to save power. A 74LS373 alone draws 30-40mA. My entire SBC with CMOS Z80, ROM, RAM and SIO draws less than 20mA. This might not seem like a big deal, but the more TTL (and NMOS) you use the higher the current draw. HCT logic gives you CMOS and TTL compatibility with low power consumption, and is more readily available.Quote from: ali6x944and the question repeats its self, how dose the pull-ups effect the VIH and VIL of the nsc800n?
Pullups don't affect input thresholds. However they do raise VOL on outputs, increase power supply current, and of course make the build more complex. Use them when necessary, avoid them if you can.
-
thanks m8Zilog only guaranteed that it would drive 2 LSTTL loads,
Z80 VOL <=0.4V @ 1.8mA, VOH >= 2.4V @ 250uA. LSTTL unit load is 400uA low and 20uA high, so it should be able to drive at least 4 LSTTL loads.
The NSC800 is rated for <=0.4V at 2mA and >=2.4V at 1mA, so it should be able to drive at least 5 LSTTL loads.
However I would avoid LSTTL if possible, for versatility and to save power. A 74LS373 alone draws 30-40mA. My entire SBC with CMOS Z80, ROM, RAM and SIO draws less than 20mA. This might not seem like a big deal, but the more TTL (and NMOS) you use the higher the current draw. HCT logic gives you CMOS and TTL compatibility with low power consumption, and is more readily available.Quote from: ali6x944and the question repeats its self, how dose the pull-ups effect the VIH and VIL of the nsc800n?
Pullups don't affect input thresholds. However they do raise VOL on outputs, increase power supply current, and of course make the build more complex. Use them when necessary, avoid them if you can.
-
Finally I got the Z80 and the MC68B50P from ebay...
I will test them and inform u ASAP.
-
also I have managed to upload the arduino bootloader in the ATMEGA32A but I'm having problems with S221116_R110517_Z80.ino its not uploading...
-
For the Z80s all 3 I bought from ebay doesn't work
this is the seller beware:
http://www.ebay.com/usr/adeleparts2010?_trksid=p2057872.m2749.l2754
now I'm trying to figure out a way to test the MC68B50P, If any one knows post please
-
For the Z80s all 3 I bought from ebay doesn't work
I have bought a few parts from this vendor and they were all good. Vintage chips are usually 'pulls' from old equipment, which have been cleaned up and relabeled. Sometimes an 'equivalent' part number is used, either to fake a higher spec chip or because they couldn't be bothered changing the label template.
this is the seller beware:
http://www.ebay.com/usr/adeleparts2010?_trksid=p2057872.m2749.l2754
Your Z80's might be 'fake', however there is a chance you just didn't test them properly. Can you show us photos of the chips and your test circuit?Quotenow I'm trying to figure out a way to test the MC68B50P, If any one knows post please
To check that a chip is not a 'fake', I start by measuring between pins with a multimeter on 'diode test'. NC (no connect) pins should be open circuit. I/O pins usually have ESD protection diodes that conduct when GND (Vss) is positive and the I/O pin is negative. Between Vss and Vcc you should see a lower diode voltage due to the larger parasitic substrate diode.
On the 6850 Vss is pin 1 and Vcc is pin 12. A 'fake' chip is more likely to have Vss on pin 12 and Vcc on pin 24. So start by doing a Diode Test on pin 1 (+) to pin 12 (-) and on pin 12 (+) to 24 (-). If 1-12 has a lower diode voltage than 12-24 then the power pins are probably correct. Now put the chip in a breadboard and apply power through a current-limited supply. Compare current draw to the specifications. The 6850 datasheet doesn't specify current draw directly, but power dissipation is stated to be 300mW typical 525W max, which corresponds to 60-105mA at 5V.
Assuming it draws close to the expected current you can then put signals on input pins and see what happens. Use pull up and pull down resistors to deselect the chip (ie. CS0/1 low, CS2 high). The data bus and other inputs should then be high impedance, while output pins will be stuck high or low. I test pin status by touching the pin with my finger (to inject AC mains noise) while monitoring the voltage with a scope probe. High impedance input pins will rectify the AC waveform as it goes below ground, while output pins will stay high or low.
If all the pin states seem to match the datasheet then you probably have a genuine chip (though it might be a different variant, eg. 6850 vs 68B50). As a further check you can enable the chip for reading (CS0/1 high, /CS2 low, /WR high, toggle E low->high) and see if anything appears on D0-D7.
To fully test it you would need to need to set up internal registers and send/receive characters. This could be done with an Arduino.
-
I searched for 'Z80' on that vendor's site and only found 'Z84C0020' (20MHz CMOS Z80 CPU). Real 20MHz Z80's are quite rare, so these are probably relabeled NMOS Z80's, which are slower and have a static current draw of ~150mA. I got a few of these 'fakes' off eBay a few years ago. In disgust I couldn't be bothered properly testing them until last week. They actually work fine at 8MHz, though I suspect they are really 4MHz parts (measured clock to address delay was ~35ns, about the same as a genuine 4MHz CMOS Z80).
If you want a CMOS Z80 then look for 8MHz or 10MHz parts, which are more likely to be correctly labeled.
-
The Z80s and MC68B50 came in a static disipative tube, these are the chips:
https://drive.google.com/file/d/0B5vW-k7HbsL4eFBDZUFldXpqa1E/view?usp=drivesdk
https://drive.google.com/file/d/0B5vW-k7HbsL4R3BmY3kzRndDWHM/view?usp=drivesdk -
Quote
On the 6850 Vss is pin 1 and Vcc is pin 12. A 'fake' chip is more likely to have Vss on pin 12 and Vcc on pin 24. So start by doing a Diode Test on pin 1 (+) to pin 12 (-) and on pin 12 (+) to 24 (-). If 1-12 has a lower diode voltage than 12-24 then the power pins are probably correct. Now put the chip in a breadboard and apply power through a current-limited supply. Compare current draw to the specifications. The 6850 datasheet doesn't specify current draw directly, but power dissipation is stated to be 300mW typical 525W max, which corresponds to 60-105mA at 5V.
for the Z80s the seller gave me a refund so that is good...
I tested both 6850 for the supply configuration and it was correct, the current draw however is not promising...
I will finish testing and inform you with the results ASAP.
-
Both chips I tested gave me a current draw of 48.5-50mA,
I think this is a step in the right direction...QuoteAssuming it draws close to the expected current you can then put signals on input pins and see what happens. Use pull up and pull down resistors to deselect the chip (ie. CS0/1 low, CS2 high). The data bus and other inputs should then be high impedance, while output pins will be stuck high or low. I test pin status by touching the pin with my finger (to inject AC mains noise) while monitoring the voltage with a scope probe. High impedance input pins will rectify the AC waveform as it goes below ground, while output pins will stay high or low.
The first chip I tested did the things you described, the second chip how ever is playing on me, the RX data is high and the data bus is high, TX and RX CLK is high,and a couple more weird things, but it dose rectify the AC noise.
-
the second chip how ever is playing on me, the RX data is high and the data bus is high, TX and RX CLK is high,and a couple more weird things
That doesn't sound good, but don't throw it away yet. The other chip is probably OK, so use it first and when you get it going you can try this one in the same circuit.
I bought a re-marked AY-3-8910 which had about 150uA pullup current on all the data lines and a peculiar signal coming out of the 'test' pin. I thought it was either faulty or fake, but then I bought a bunch more genuine chips which did the same thing. Turns out that early AY-3-8910's have pullups on the data bus, but the later 'A' version doesn't. This change appears to be undocumented (I cannot find any reference to it in the datasheets).
The attached photo shows my current stash of AY-3-8910's bought from various eBay sellers. You can clearly see differences between those that have been re-marked and the 'genuine' chips which still have their original markings. The originals have dull markings, clear injection marks, and some scuffing and scratches. The two re-marked chips have suspiciously bright markings, and the injection marks are almost invisible because the surface has been sanded down and 'blacktopped'. Also notice that the two 'new' chips have the General Instrument logo, but visibly older chips have the Microchip Logo - which is not possible unless the 'new' chips have been re-marked because GI spun off their IC production to Microchip in 1987.
However despite their dodgy history all these chips work perfectly (as do the 6 others that are in use) which proves that they are actually genuine! The latest batch I purchased all had original markings. This suggests that at least some suppliers may be rethinking their strategy. A beat-up old chip might not look so nice, but inspires more confidence than one which has had the original markings filed off.
Many of these old chips are now 'vintage' and so may be worth more if they still have the original markings. Note the RAD38910 at the bottom right of the photo. This was the Radofin 'in-house' version that was used in the Mattel Aquarius. Apart from the label it's actually identical to a normal AY-3-8910.
-
The markings on mine are rather dull too, which is promising but I can not read the date code on it quite well...
Question: when was the MC68B50 discontinued? This will give a good indication for us to determine if its fake or not
-
They appear to be 'blacktopped' (ie. painted matt black, including over the injections marks) which indicates that they are re-marked - though not necessarily fake. Compare to the attached photo of two original Motorola chips in my collection.
The only way to really be sure if it's a fake or not is try it in a circuit. If it works as expected then it is at least a variant of the MC6850.
BTW by comparing package shapes I figured out that my '20MHz' Z80's are actually Sharp LH0080, a popular 2nd source for the 4MHz NMOS Z80.
-
Well, I think that we are going in the right direction
But remember the 74LS373, I tested it with my TL866CS and it was bricked...
I will however buy a new chip today, hopefully...
-
I got it now, no worries
-
I got myself 4 74HC373 and 1 Z80 CPU for reference...
all good now, sadly enough the local waves store does not have a UART chip like MC68B50 or the Z80 SIO....
but its ok
-
I'm trying to make the clock stop circuit work, but with no luck...
Also I have cleaned up the wiring and used 74LS04 inverter to replace the shorted input NAND gates.
https://drive.google.com/file/d/0B5vW-k7HbsL4azBDVW5DWGJoeHc/view?usp=drivesdk
Note that because I couldn't make the clock stop circuit -in the right- work, I have just contacted Xin And Xout to a 4MHz crystal and its supporting circuitry. -
Note that active high signals like S0 and S1 light up when they are active while active low signals like /WR and /RD and IO//M light up when its low.
-
It kind of works now after I changed the transistor, it stops the cpu's operation and still keeps the address and data bus unchanged even if the cpu is resetted
-
I think we are done with CPU control circuitry, the CPU clock stop circuit is working and the reset is working...
now I have done some work regarding the memory map of the CPU, and I really want to implement somethings like Basic, so I need some advice...
so far I know that the NSC800 can address 64K bytes of memory, regardless of the type, so what I understand is that I have a 64k byte margin to fit the ROM and RAM stuff in...right?
so I have been thinking of using the first 16K bytes for ROM both for the BASIC and the OS ROM images which I can easily fit in a 39SF010A, it will start from address 0x00 to 0x1F400.
while the rest 48K be RAM, starting from 0x1F401 to 0x5DBFF. NOTE that the ram is made with 3 chips, 2 8K and 1 32k RAMs or with 2 32K byte RAMs with one of them with addresses A14-A12 Pulled low.
alternatively I thought of using only 32K ; because it would make it easier to make.
-
so far I know that the NSC800 can address 64K bytes of memory, regardless of the type, so what I understand is that I have a 64k byte margin to fit the ROM and RAM stuff in...right?
Yes.Quotealternatively I thought of using only 32K ; because it would make it easier to make.
32K should be plenty, unless you are running CP/M in which case you need RAM at 0x0000-7FFF. So put your 32K RAM at 0x8000-FFFF, then you only need to decode A15 (low = ROM, high = RAM). If later you decide to run CP/M you can add another 32K RAM, switched in over the ROM to give a total of 64K. -
Quote
How can I have 64K of RAM and have ROM? Or how can I switch from RAM to ROM if the max address is the same? Also is microsoft BASIC an OS or a system language?Quotealternatively I thought of using only 32K ; because it would make it easier to make.
32K should be plenty, unless you are running CP/M in which case you need RAM at 0x0000-7FFF. So put your 32K RAM at 0x8000-FFFF, then you only need to decode A15 (low = ROM, high = RAM). If later you decide to run CP/M you can add another 32K RAM, switched in over the ROM to give a total of 64K.
And I want to add on the memory map another consideration, I'll use a GDC which is the uPD7220, do I make it share RAM with the CPU or have its own separate RAM? -
How can I have 64K of RAM and have ROM? Or how can I switch from RAM to ROM if the max address is the same?
You can have ROM and RAM at the same address if only one of them has its outputs enabled at a time. To switch between them you can have a latch (accessed at an I/O location) which steers decoded /RD to either ROM /OE or RAM /OE. RAM /CE can be activated for both reading and writing, so writing to 'ROM' causes data to be stored in RAM even when the ROM is selected for reading.
On power up the latch is reset, so the CPU gets valid instructions and vectors from ROM. You can then copy code from ROM to RAM, switch to RAM and continue processing with all RAM. This is practically required for CP/M because 'transient' programs are loaded from disk starting at location 0x0100. It also makes user RST vectors more efficient because you can modify them directly, rather than having fixed vectors in ROM which jump into RAM at a higher address.
QuoteAlso is microsoft BASIC an OS or a system language?
It can be both. The versions designed for ROM based computers have the OS built in. Since BASIC is interpreted it can also act as a user interface, with 'direct' commands that are typed in by the user. The original IBM PC had BASIC in ROM. If you didn't have a boot disk (or a disk drive, which was optional!) it would boot into BASIC.QuoteI'll use a GDC which is the uPD7220, do I make it share RAM with the CPU or have its own separate RAM?
The uPD7220 has its own separate RAM. The host CPU interface has only 2 memory locations, which are usually mapped into I/O space. It can also access the host memory via DMA, but this is also memory <-> I/O.
-
thanks m8
and for the full 64K RAM-ROM switching I was thinking of using the control and status outputs in the NCS800; so depending on the Machine cycle the following happens:
A) in Opcode Fetch: S0 & S1 & /M & /WR are active, so the ROM is selected, and read from.
B) in Memory Read: S1 & /M & /WR are active, so the RAM is selected, and read from.
C) in Memory Write: S0 & /M & /RD are active, so the RAM is selected, and written to.
in a similar way, we could do the I/O's and peripherals... I guess
but I'm not sure how to create the logic for the switching and what are the downsides to the full 64K RAM-ROM switching method...
-
A) in Opcode Fetch: S0 & S1 & /M & /WR are active, so the ROM is selected, and read from.
Unfortunately that won't work because many instructions have immediate data after the opcode, which would be read from the wrong memory.
B) in Memory Read: S1 & /M &/WR/RD are active, so the RAM is selected, and read from.QuoteC) in Memory Write: S0 & /M &
This will work. You are effectively writing 'under' the ROM into RAM. The ROM could even still be selected, but won't interfere because it only responds to reads (S0 & /M & /RD -> /OE)./RD/WR are active, so the RAM is selected, and written to.QuoteI'm not sure how to create the logic for the switching
You just need 1 bit of output at some I/O location, going to a MUX that steers /OE to ROM or RAM. This could be done with eg. a D F/F and and a few NAND gates. The output bit must be reset on power up (and perhaps hardware reset) to ensure that the machine starts with the system ROM active, so use a F/F with reset input or an I/O chip which sets its outputs to known states on power up.
This is commonly called 'bank switching' or 'sideways RAM/ROM' and was done in many vintage home computers such the Amstrad CPC, Commodore 64 and BBC micro.Quoteand what are the downsides to the full 64K RAM-ROM switching method...
Switching between ROM and RAM can be tricky because you can't switch the ROM out while you are in it unless the underlying RAM has valid instructions. One way to deal with this is to simply copy the code from ROM to RAM before switching. Another way is to put a small routine in 'common' ROM or RAM which has the switching code in it. With this method you can have an almost unlimited number of ROMs or RAM banks in the same space.
For example The Amstrad CPC6128 has 128k of RAM plus lower and upper 16k ROMs. The memory is divided into 4 banks which can be mapped to various combinations of ROM and RAM. When ROM is enabled at 0x0000-3FFF or 0xC000-7FFF the 'underlying' RAM can still be written to. Bank switching is controlled by an output port made from a PAL which has been programmed with a useful selection of mappings. This enables the machine to run CP/M with almost 64k of TPA (Transient Program Area) plus 16k of screen RAM and another 48k of RAM which can be used as a RAM disk or for storing data. It also allows games to use the full 128k and still access the system and disk ROMs if needed. Up to 252 ROMs can be added as well as another 4MB of RAM.
Another downside is that RAM can be corrupted by errant writes, whereas ROM is immune. This shouldn't happen unless you have a hardware fault or buggy software, but reduces reliability in harsh environments (RAM can be corrupted by power glitches or brownouts).
The memory expansion I developed for the Mattel Aquarius has 32k RAM, 16k of which can be mapped into game cartridge ROM space (creating a 'soft' ROM cartridge). In this mode the RAM is enabled for reading only (no writes) because several games are known to 'randomly' write to the ROM while running (I don't know whether this is due to bugs or by design). I use a latch that is set via an I/O port but only reset on power up. This prevents the 'soft' ROM from switching itself out once it has been activated.