Shift838 Posted March 2, 2021 Share Posted March 2, 2021 (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 Bottom Installed in Geneve and all wired up! Powered on... Decided to go ahead and replace my LED since it was old and dull. Not now! chkdsk command shows the correct memory memtest shows good too.. New hopefully final design: Top: Bottom: Edited March 2, 2021 by Shift838 7 Quote Link to comment Share on other sites More sharing options...
GDMike Posted March 2, 2021 Share Posted March 2, 2021 (edited) What would be the benefit. Thank you in advance So we couldn't get a 1 mb card? Edited March 2, 2021 by GDMike Quote Link to comment Share on other sites More sharing options...
Shift838 Posted March 2, 2021 Author Share Posted March 2, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
RickyDean Posted March 2, 2021 Share Posted March 2, 2021 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...? 1 Quote Link to comment Share on other sites More sharing options...
RickyDean Posted March 2, 2021 Share Posted March 2, 2021 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. 3 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 2, 2021 Share Posted March 2, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted March 2, 2021 Share Posted March 2, 2021 Mmm, Ramen!? 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted March 2, 2021 Share Posted March 2, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted March 2, 2021 Share Posted March 2, 2021 I should also mention that I don't recall if anyone confirmed the test results on real hardware. 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 2, 2021 Share Posted March 2, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted March 2, 2021 Share Posted March 2, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 2, 2021 Share Posted March 2, 2021 (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 March 2, 2021 by mizapf 5 Quote Link to comment Share on other sites More sharing options...
Shift838 Posted March 2, 2021 Author Share Posted March 2, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 2, 2021 Share Posted March 2, 2021 (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 March 2, 2021 by mizapf Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted March 2, 2021 Share Posted March 2, 2021 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! 2 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 2, 2021 Share Posted March 2, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
RickyDean Posted March 2, 2021 Share Posted March 2, 2021 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....? 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 2, 2021 Share Posted March 2, 2021 Is that something to eat or drink? Quote Link to comment Share on other sites More sharing options...
GDMike Posted March 2, 2021 Share Posted March 2, 2021 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? Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted March 2, 2021 Share Posted March 2, 2021 3 hours ago, RickyDean said: I'll take 3 PAL's.... I'll be your pal! 1 Quote Link to comment Share on other sites More sharing options...
RickyDean Posted March 3, 2021 Share Posted March 3, 2021 2 hours ago, HOME AUTOMATION said: I'll be your pal! Ok, cable man.....lol. 1 1 Quote Link to comment Share on other sites More sharing options...
Shift838 Posted March 4, 2021 Author Share Posted March 4, 2021 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. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted March 4, 2021 Share Posted March 4, 2021 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? 1 1 Quote Link to comment Share on other sites More sharing options...
RickyDean Posted March 4, 2021 Share Posted March 4, 2021 Yeh, I've thought, ever since I first got my Geneves, that it would be possible to design a sram board to provide maximum memory expansion for the Geneves. Maybe using methods described here https://electronics.stackexchange.com/questions/201592/modern-replacements-for-old-dram-memory-chips/201703#201703,and other places. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 4, 2021 Share Posted March 4, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.