Jump to content
Shift838

SHIFT838 384k Module for Geneve 9640

Recommended Posts

Posted (edited)

All,

 

I have been working on designing a new 384k daughter board to be mounted into the current SRAM socket without having to piggyback chips for the original 3x128k mod to get the 384k or install additional sockets for the a 32 pin dip 512k x 8 chip.

 

I received a few test boards to verify the design of the PCB.  Between referencing documentation that @InsaneMultitasker and @fabrice montupet website for details.  I came up with this PCB.  I did find a trace I missed, but it was an easy fix.  This is not going to be the final PCB as the SMD 1N4148 diodes are a hell of a lot smaller than I thought.  

 

I have been able to rework the board to allow for through-hole diodes.  However, in order to keep this board small enough to just plug into the existing socket I had to go with a SMD version of the 512k x 8.

 

The same wire management can be used.

 

This board will require a handful of wires to be soldered to the header pins and ran to the respective connections of the Gate Array and U29 LS244.

 

Attached are some photos along with what I believe will be the final board rendering.  I will be order a few test boards for this revision next day or so.  I want to go over it a few more times.

 

If there is interest I will make a run.  I will be posting a poll, so please if you are interested please answer the poll.

 

I can provide a DIY Kit and Assembled/Tested in the poll (Estimated prices will be in the Poll)

 

Intial Board design:

 

Top

TOP.jpg

 

Bottom

BOTTOM.jpg

 

Installed in Geneve and all wired up!

384k installed.jpg

 

Powered on...  Decided to go ahead and replace my LED since it was old and dull.  Not now!

running.jpg

 

chkdsk command shows the correct memory

chkdsk.jpg

 

memtest shows good too..

memtest.jpg

 

New hopefully final design:

Top:

v1.0 TOP.png

 

Bottom:

V1.0 BOTTOM.png

Edited by Shift838
  • Like 7

Share this post


Link to post
Share on other sites
Posted (edited)

What would be the benefit. 

Thank you in advance

So we couldn't get a 1 mb card?

Edited by GDMike

Share this post


Link to post
Share on other sites

The module give you access to additional 384k of fast ram that

 can be used for multitasking.  This is a cheaper solution than having to hope to find a myarc  512k card then modifying it for the Geneve.  
 

 

  • Like 2

Share this post


Link to post
Share on other sites

I like this solution, think @GDMike, is looking at the possibility of a sram card that could do the same as the modified Myarc dram cards. At least that's what I would be thinking...😆

  • Thanks 1

Share this post


Link to post
Share on other sites

As it so happens, I am looking at going the 512K route on my PFM Geneve, I'm repairing. Was just studying @fabrice montupet
's details a few minutes ago. I have installed sips instead of sockets in the positions for the sram and pfm+/bios chips.

  • Like 3

Share this post


Link to post
Share on other sites

How do you select the other SRAM pages? I only found the RAMEN and RAMEN-X outputs on the Gate array in the schematics; for that reason I limited the SRAM expansion in the emulation to 32K.

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, mizapf said:

How do you select the other SRAM pages? I only found the RAMEN and RAMEN-X outputs on the Gate array in the schematics; for that reason I limited the SRAM expansion in the emulation to 32K.

Address lines are picked up from the board and decoded.  See Fabrice's website for the cleanest instructions and wiring information.

 

Some time ago I believe that you proved, based on timing, that pages C0-E7 (those outside of the usual 64K SRMA) were not truly fast ram as previously thought. 

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, InsaneMultitasker said:

Some time ago I believe that you proved, based on timing, that pages C0-E7 (those outside of the usual 64K SRMA) were not truly fast ram as previously thought. 

As you mention that ... yes, I think I remember that accesses to pages C0-E7 cause a wait state to be inserted. That means, regardless of how the decoding of further pages is done, you cannot make the Gate Array believe in that extra 0-ws RAM.

  • Like 1

Share this post


Link to post
Share on other sites
50 minutes ago, mizapf said:

As you mention that ... yes, I think I remember that accesses to pages C0-E7 cause a wait state to be inserted. That means, regardless of how the decoding of further pages is done, you cannot make the Gate Array believe in that extra 0-ws RAM.

Would you have time and desire to create a test program to validate the wait state/speed on real hardware?  I would like to change the OS memory identification routine to flag pages C0-E7 as SLOW ram if in fact the wait state is inserted.  The OS presently treats the pages as FAST ram.

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

Here you are ... including source code. I tried it on my real Geneve.

 

(Actually, I'm not that fast, but I wrote this program already a year ago.)

speed.dsk

 

Edit: The program runs some read iterations on different pages; the results are 10ths of seconds. You will see that for a 1 waitstate page you get about 110, while a 0 waitstate page delivers about 100. I adjusted the iteration count so that one wait state delivers 1 second of added runtime.

Edited by mizapf
  • Like 5

Share this post


Link to post
Share on other sites
2 hours ago, mizapf said:

Here you are ... including source code. I tried it on my real Geneve.

 

(Actually, I'm not that fast, but I wrote this program already a year ago.)

speed.dsk 360 kB · 3 downloads

Here are the results of your program on my Geneve with 384k upgrade.

 

 

wait-results.jpg

  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)

Yes, as expected: Only the pages E8-EF have 0 waitstate. If you like you can change the program to test the SRAM pages only.

 

Edit: The pages to be tested are defined in

PGLIST BYTE >00,>20,>40,>60,>80,>A0,>BA,>C0,>E0,>E8,>EC,>F0,>FF

 

FF is the stop code. The length is not limited.

 

You could test all the pages from C0-EF, but I think testing C0, E0, E8, and EC as above should suffice.

Edited by mizapf

Share this post


Link to post
Share on other sites

The ROM speed is interesting as at one time there was documentation stating it was 0-wait state.

 

I will correct the OS memory test to count pages C0-E7 as 1-wait slow RAM

 

 

@Shift838 -nice board and implementation!

  • Like 2

Share this post


Link to post
Share on other sites

The ROM wait state is really silly. The wait states are triggered by the Gate array but created by the PAL; its output (18) is what goes into the READY input of the 9995. One could consider reprogramming the PAL to avoid wait states for accesses to the whole SRAM and EPROM region (C0-FF).

 

Too bad that all its inputs are used, although input 5  (CRU bit 23) has an obscure meaning, so maybe this could be replaced.

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, mizapf said:

The ROM wait state is really silly. The wait states are triggered by the Gate array but created by the PAL; its output (18) is what goes into the READY input of the 9995. One could consider reprogramming the PAL to avoid wait states for accesses to the whole SRAM and EPROM region (C0-FF).

 

Too bad that all its inputs are used, although input 5  (CRU bit 23) has an obscure meaning, so maybe this could be replaced.

I'll take 3 PAL's....😃

  • Like 1

Share this post


Link to post
Share on other sites
19 hours ago, Shift838 said:

The module give you access to additional 384k of fast ram that

 can be used for multitasking.  This is a cheaper solution than having to hope to find a myarc  512k card then modifying it for the Geneve.  
 

would it help in making a ramdisk?

Share this post


Link to post
Share on other sites

i have ordered a few new PCB's with a couple of revisions to test.  They should be shipped 3/9 or 3/10 (i'm told).  once I get them I can solder one up and test it.  If all goes well then I can release it.

 

 

Share this post


Link to post
Share on other sites
On 3/2/2021 at 12:39 PM, mizapf said:

Yes, as expected: Only the pages E8-EF have 0 waitstate. If you like you can change the program to test the SRAM pages only.

 

The Geneve OS source code refers to a 1MB option that as best I can tell was going to be on the Geneve itself.   Additionally, the entire range of pages from >00 to >7F is encoded to be classified as FAST RAM or 0-wait state, with routines written to test for the existence of page >40 as the determining factor.   Is there something we've missed with the current hardware?  Maybe another board was planned that could use SRAM in place of DRAM? 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

The wait state behavior is buried inside the Gate Array and the PAL. On the board, there is not even a place for a memory expansion; you cannot solder DRAMs on top of each other. So the "future expansion" was meant to be in the infinite future, or possibly in another time line.

 

Or, in other words: These things may have been planned originally, but the eventual design of the board and the custom chips made them moot. But obviously, no one cared to rewrite these items in the specifications.

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...