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.
