Hi John,
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
https://groups.google.com/forum/?fromgroups#!topic/n8vem-s100/rjrJQdXRHNE
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 ??)
My wish for 2015 :-)
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
David Fry
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!
>
> John
>
>
> On Sunday, December 21, 2014 10:13:37 PM UTC+1, David Fry wrote:
>
>> Hi John,
>>
>> 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.
>>
>> regards
>>
>> David Fry
>>
>>
>> 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
>>>
>>>
>>>
>>>
>>>
>>> *From:* [email protected] [mailto:[email protected]] *On
>>> Behalf Of *Richard Cini
>>> *Sent:* Sunday, December 21, 2014 2:28 PM
>>> *To:* S100-Post
>>> *Subject:* Re: [N8VEM-S100:5874] Re: S100 Board anomalies
>>>
>>>
>>>
>>> David —
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> Thanks!
>>>
>>>
>>>
>>> Rich
>>>
>>>
>>>
>>> --
>>>
>>> Rich Cini
>>>
>>> Collector of Classic Computers
>>>
>>> Build Master and lead engineer, Altair32 Emulator
>>>
>>> http://www.classiccmp.org/cini
>>>
>>> http://www.classiccmp.org/altair32
>>>
>>>
>>>
>>> *From: *David Fry <[email protected]>
>>> *Reply-To: *S100-Post <[email protected]>
>>> *Date: *Sunday, December 21, 2014 at 3:46 AM
>>> *To: *S100-Post <[email protected]>
>>> *Subject: *[N8VEM-S100:5874] Re: S100 Board anomalies
>>>
>>>
>>>
>>> Hi Rich,
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>> https://groups.google.com/forum/?fromgroups#!searchin/n8vem-s100/ds12885/n8vem-s100/Ba5_Gwva170/H6AD-JOSQXgJ
>>>
>>>
>>>
>>>
>>>
>>> hope this helps
>>>
>>>
>>>
>>> David Fry
>>> On Sunday, December 21, 2014 2:56:14 AM UTC, AltairManRich wrote:
>>>
>>> All —
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> Rich
>>>
>>>
>>>
>>> --
>>>
>>> Rich Cini
>>>
>>> Collector of Classic Computers
>>>
>>> Build Master and lead engineer, Altair32 Emulator
>>>
>>> http://www.classiccmp.org/cini
>>>
>>> http://www.classiccmp.org/altair32
>>>
>>> --
>>> 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 [email protected].
>>> 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 [email protected].
>>> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
