Hi David, thanks for help/suggestions. First the main reason for the next prototype 80386 is to test out my logic/GAL programming for the 80486. Going to the 80486 is not as simple as you might first think from the 80386. The way the data is presented to the bus buffers is completely different for 8 and 16 bit data and requires a number of extra drivers. The chip is also larger, the net result being that the board is extremely crowded. The only way out is to replace a number of the 74LSxx chips with a few GALs. The actual circuit on the current 80386 board is actually largely unchanged. That board works fine with all our current S100 boards – the result of 7 prototypes over 2 years! The clock speed issue is something I spent a great deal of time fooling around with Dave. The complication with the 80386 is that there in this situation 3 clock speeds that are inter-related and must be switched glitch free for PM and S100 access. In fact the reason I have used the AMD chip is the fact that it has no restrictions on minimal clock rates (can go to zero), not so for the Intel chip. I agree one could play around with the clock circuit more but frankly I have looked at the 80386 as only a stepping stone to the 80486. That is really our final 8086 family S100 bus CPU board. It has everything. 8, 16 & 32 bit addressing. A single input clock frequency, math coprocessor etc. In theory it should work with old 8 bit RAM boards! My only worry is the clock speed switching between the (slow) S100 bus and our full speed overhead PM bus. I am getting conflicting reads in the literature as to how tolerant these chips are to “on the fly” clock frequency changes. One nice thing about using GALs is that now board layout changes are quick and easy. This board will be my main focus for the next few months. If I can pull it off it would far super-seed all our other 8086 family boards. Also the VGA boards become easy (see below). I will take a look at GAL’s later for a clock circuit, really good idea. So far I have just used them for AND,OR,NAND circuits. As a flip-flop is interesting for clock frequency changes. The one complication on the 80386 board that there is currently a ‘kludge’ to do with the pWR* signal. On the 80386 (and I think the 80486) it seems to hang on too long after the address lines to RAM and is unstable on our S100 boards with the resulting errors. I make a shorter pulse on the board but it’s not really done properly and is pulling the total board clock speed down. On the 80486 I will try and do it better. Now on the VGA boards I have done no less than 10 prototypes. Have to admit I was somewhat ignorant at the start and completely underestimated the difficulty of slamming a VGA chip on to the S100 bus. There are multiple issues – too many to go into here, but the main one has to do with the fact that VGA chips like the Cirrus and Trident chips expect not only 8 and 16 bit data but also absolutely require you to send initial 16 bit data in two back to back 8 byte chunks. This is a problem for all our 8086 family boards. 16 bit data simply pulls sXTRQ* low and the S100 boards process it as 16 bit data. I tried to build VGA boards that would trap the two 8 bit data chunks, synthesize two separate Rd/Wr signals on the VGA boards and fool the VGA chips into sending/receiving 8+8 bits of data. It worked for the 8086 but was clock speed sensitive and was unreliable above 6MHz. Could never get it to work with the 80286 and the above pWR* issue with the 80386 was a major problem. Compounding the problem was wait states put out from time to time by the VGA chip itself. In the end I simply gave up on this approach for a generalized solution. I am currently doing a VGA 8 bit only VGA board (for our 8088 board). The plan was to also use this board with the 80486 board witch also has 8+8 capability, but as well true 16 bit transfers. That one looks completely reliable at any speed. All this leaves us with the 8086 and 80286 boards. The only way I see to getting these boards to work reliably at high speeds is to do another version of these boards with the 8+8 circuit directly on the board. The only S100 board I have seen this done for was the TecMar 8086 board http://s100computers.com/Hardware%20Folder/TecMar/8086%20Board/8086%20Board.htm It’s a bit of a splice but frankly I’m not sure it’s worth it if we get the 80486 working. Will wait and see. The SMD based 32/64MB ARM board is really straightforward being just the CPU address and data lines extended. I don’t anticipate any changes going forward. I did howevert bring out the four parity lines on the overhead connector on the 80486 board for a future DRAM board! Thanks for the supporting comments Dave, it’s all fun. Wish I did not have to travel so much but by mid January I should be able to get back to things. Have a good Christmas and New Year yourself John From: n8vem...@googlegroups.com [mailto:n8vem...@googlegroups.com] On Behalf Of David Fry
Sent: Monday, December 22, 2014 12:49 PM
To: n8vem...@googlegroups.com
Subject: Re: [N8VEM-S100:5881] Re: S100 Board anomalies I'll post a picture on a new thread when I get good enough light to take a picture. Interesting that you are going to further develop the 80386 board, in what way would this new board be different from the existing 80386 board ? One thought that had crossed my mind (which I think I mentioned before) would be to put the clock generator logic into a PAL to get the board upto 66Mhz (33mhz 386 internal speed) with a /8 for a 8.25Mhz S100 bus clock speed. From examining datasheets of the 74HCT93 some manufacturer versions are rated at a clock speed of 30Mhz (Texas Instruments) but others are rated at 70Mhz (NXP and Philips) so that chip may not be suitable, PALs on the other hand could get you to that speed, but any increase in the speed of the 80386 board would neccesitate that you address the timing issue that you highlighted on the 32/64MB RAM daugterboard in the thread below I have seen the KiCad files for your new 32/64MB RAM board with the SRAM chips mounted directly to the board (much neater) but it may be worth sorting out the above timing problem before the board is released for production (maybe another PAL ??) It would be nice to see a resolution to the 80286 CPU Board not working with the S100 VGA board you're working on, if the 80486 is going to turn out to be a longer term project then the VGA board functionality with existing CPU boards (80286 and 80386 if poss) becomes a little more important.(for me at least) I take my hat off to you John, I don't know how you find the time to get so much done for the S100 computer community, I barely get enough time to build the hardware at the moment, I'm hoping that in 2015 I will find the time to start working with the software in my S100 system. Wishing you a Happy Christmas and a productive New Year
On Monday, December 22, 2014 10:32:51 AM UTC, monahanz wrote:
Glad you got that 80386 board working. Had not heard back from anybody else so far. I'm actually doing another prototype of this board substituting a few GAL's instead of 74LSxx chips as an intermediate stepping stone to the 80486. One thing I'm a bit worried on the 80486 is the fact that the input CPU clock may not tolerate fast clock frequency switching between the S100 bus access (slow) and the protected RAM (fast) access. I also have a 32/64 MB daughter RAM prototype board for both CPU boards -- like our earlier one -- but this time the RAM chips are soldered directly to the board. Expensive but a cleaner/nicer board!
On Sunday, December 21, 2014 10:13:37 PM UTC+1, David Fry wrote:
Yes, I kind of worked that out in the end :-) What had me puzzled was that your demo video of the 80386 board didnt show any holes ('.') when you performed a memory map of the 1MB address space, you must have been using a older firmware at that time. Since this was first power up of my 80386 board I thought I had a wierd addressing problem or a duff cpu, In the end I dropped the 80386 roms onto my 80286 board and this confirmed it was software and not hardware.
On Sunday, December 21, 2014 8:27:48 PM UTC, monahanz wrote:
Again traveling David, so going on memory. You will see that the MemoryMap routine in either the Z80,8086 or 80386 monitors simply looks to see if the RAM area is a 0FFH if so it’s assumed to be non RAM or non ROM area. So if FF happens to be at an 100H boundary then it would be flagged as a RAM hole. The test could be clearly more extensive such as looking at surrounding bytes (or words). However the original code was for a Z80 ROM where space is limited. The test simply see if the address is 0FFH, If not can the byte be inverted if RAM if not ROM! Some day I will add more tests for the 80386 monitor John Thanks for the tips. I will look at the ROM later today. That’s probably it since it works fine. On the RTC, that’s an interesting thread. I guess it makes sense to ship the chip essentially “off”. I’ll have to look at the time setting code in the 8086 monitor, though, to see if it actually enables the clock or not. Otherwise I’ll grab the z-rtc program and give that a try. Collector of Classic Computers Build Master and lead engineer, Altair32 Emulator I can probably answer two of your problems, the memory map showing a '.' in the prom area is probably where the memory map routine samples a memory value and the value sampled turns out to be FFH, I've just completed my 80386 board and have been chasing my tail all last evening on the same issue where that also prints two '.'s in the prom area. Open your Z80 v4.8 monitor in your programmer software or hex editor and look at memory location 0F00H which would correspond to EF00H in your memory map, I guessing it will be an FFH. you can confirm this behaviour by examining the monitor code for memory map generation. I use Z80 monitor version 5.02 and that one displays the memory map fine as it doesnt contain FFH in the sampled locations. With regard to your Real Time clock not working, the RTC chips are shipped with the internal register set to stop clock, view the following thread, particularly Gary's last post to figure out how to start the clock David Fry
On Sunday, December 21, 2014 2:56:14 AM UTC, AltairManRich wrote: I was playing around, again, with my Z80/8088/PropIO/4MB/PC-AT board set and I still really can’t get it working properly. I have gone over the boards and I’m pretty sure that there aren’t any soldering issues. I’ve also re-flashed the ROMs just in case. Z80 version is 4.8. 8086 version is 10.33a. I will say that I’ve never had a problem with the Z80 board in my old configuration of a legacy 8-bit serial card and CompuPro 64k RAM board. Here are some of the oddities I’m seeing: - When doing a memory map from the Z80, the ROM is shown as all “p” except for the xxFx address which is a “.”. For RAM, it does show “R”. It doesn’t matter where I locate the ROM. So…
D000 R R R R R R R R R R R R R R R R E000 p p p p p p p p p p p p p p p . F000 R R R R R R R R R R R R R R R R - In the 8086 monitor, if I use the “R” command, it goes into lala land when printing the flags, printing a continuous stream of “0” after half of the flags are printed
- In the 8086 monitor, if I use the “A” memory map command, I get something that looks like a map, but I get addresses like 00000,00000,80000,C0000 and then each line is a mix of R and p. Finally it goes into lala land at the end, continuously printing spaces.
- The RTC on the MSDOS board will not store the date/time and it returns garbage when using the monitor commands which read them. I’ve swapped the chip and the battery is installed. As an example time “25:06:00” and date "20<7/26/14”. It appears that the clock isn’t running and can’t be set.
I reduced the system to the PropIO, 4mb RAM and Z80 card so I could test the RAM (at least the first 1mb) using a combination of the N and J commands. It reported bad memory in each segment in the E000-EFFF range. This corresponds to where my monitor resides in the first 64k, so maybe this is expected behavior. No other memory errors were reported. I’d have to say that the first 1MB is probably OK So that leaves the 8088 or MSDOS boards as being the problem. Since the monitor anomalies occur without the MSDOS board, it has to be a problem with the CPU card. John, by chance do you have one of the 8086 cards for sale? Maybe I’ll start from scratch using the 8086 card. Collector of Classic Computers Build Master and lead engineer, Altair32 Emulator
--
You received this message because you are subscribed to the Google Groups "N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem-s...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout. --
You received this message because you are subscribed to the Google Groups "N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem-s...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem-s100+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout. |