250520 7xsys concept release

[7alken]

Hi all, after few months of disability by crippled nerve and leg (last OT question in Nov,2024 about QEMU...) I am already finally near to KiCad and PCB design again. I am not quick, nor experienced, so, I am steadily dreaming )) ... and here is first draft of something I have in mnd for months or years, but last info about JLCPCB protyping of 50x50mm (51x51) 6+ layer board led me finally that feasibility of this is close; I want to do something which is capable of RomWBW and Fuzix too, but its far more for my own experiments and testing on real hardware, mostly old one, but ALSO quite new, and not to ruin myself, nor you; this is not something which will be "sent to factory", no, I hope that also(?) new generation will come with better eyes and hands and slightly shifted meaning of "retro" ))

attached is file with PNG switchable over base to see some variants of using this 3V3 (and lower, where appropriate), 7xmod compute/standalone with 7xmem SRAM/SDRAM (or whatever) and decoupled by CPLD (having also MMU and life complicated even by BGA, probably with tiny MHP30 heatpad and hot air), slower(?), 16bit to backplane (I have my own 30pin 2mm conn specified, but complete document will be large, and only after next real iterations on several very different examples, fingers Xed)

Still lot of work on this...
Petr
(treat me pls, as a old dreaming kid in 70's garage somewhere over the ocean, tnx;)

[7alken]

here is the 7xmem pinout as of now, in theory; prototype PCB ASAP; needed that BGA testing flex-zif prototype(s)
 ... there are bga90/54/48, mostly probably lowest acceptable pitch 0.8mm;
for usage with small MHP30 heatpad, chips are grouped by 4 max to solder at once, but its okay to have only single there and no demux at all

7xmem - interface specs
============================
 - 1) std async SRAM / sync SDRAM modules
 - 2) custom - sync 60x BUS modules (7xmod CPLD controller)
 - 3) custom - serial PSRAM with on module CPLD exposing async SRAM from DDR PSRAM, HyperRAM, OctaRAM
 
  connector pinout
  ===================

     32 O    A00-A31 / SDRAM JEDEC: A0-12 BA0-1 DQM0-3 (20x ... A20-31 (8bit std) are possible for banking per chip(s) with demux 74lvc138 74lvc154)
     64 IO   D00-D31

     65 O    SRAM /CS (controls 74lvc138 / 74lvc154)
     66 O    SRAM /WE
     67 O    SRAM /OE

     68 I    VDD MODULE DETECT (may disconnect 7xmod MINI SRAM)

     69 -    GND
     70 -    GND
     71 -    GND
     72 -    VDD 3V3 2V5 1V8 (level from 7xmod M-LDO)
     73 -    VDD dtto
     74 -    VDD dtto

     75 O    SDRAM JEDEC /CS (controls 74lvc138 / 74lvc154)
     76 O    SDRAM JEDEC /WE
     77 O    SDRAM JEDEC /RAS
     78 O    SDRAM JEDEC /CAS
     79 O    SDRAM JEDEC CKE
     80 O    SDRAM JEDEC CLK

initial post about 7xbus precursor are here:
https://groups.google.com/g/retro-comp/c/hVPhehlom54/m/5zpbtRggBgAJ

but it then developed into something simpler on that 2x15 2mm pitch connectors,

mostly for LCDs over MIPI DBI-B or DBI-C, but so also IDE and general SPI:

Pin   Signal Name     Full function 16-pin DBI B       8-pin SPI DBI-C               IDE PIO Mode (0, 1, 2, 16-bit)
00      GA0                    Data bit 0 (A gpio)                                                             IDE D0

01      GA1                    Data bit 1 (A gpio)                                                             IDE D1

02      GA2                    Data bit 2 (A gpio)                                                             IDE D2

03      GA3                    Data bit 3 (A gpio)                                                             IDE D3

04      GA4                    Data bit 4 (A gpio)                                                             IDE D4

05      GA5                    Data bit 5 (A gpio)                                                             IDE D5

06      GA6                    Data bit 6 (A gpio)                                                             IDE D6

07      GA7                    Data bit 7 (A gpio)                                                             IDE D7

08      GB0                    Data bit 0 (B gpio)                                                             IDE D8

09      GB1                    Data bit 1 (B gpio)                                                             IDE D9

10      GB2                    Data bit 2 (B gpio)                                                             IDE D10

11      GB3                    Data bit 3 (B gpio)                                                             IDE D11

12      GB4                    Data bit 4 (B gpio)                                                             IDE D12

13      GB5                    Data bit 5 (B gpio)                                                             IDE D13

14      GB6                    Data bit 6 (B gpio)                                                             IDE D14

15      GB7                    Data bit 7 (B gpio)                                                             IDE D15

16      GCS0                 Select bit 0   (C gpio 4)                                                     IDE A0

17      GCS1                 Select bit 1   (C gpio 5)                                                     IDE A1

18      GCS2                 Select bit 2   (C gpio 6)                                                     IDE A2

19      INT#                  HW interrupt   (mb in)

20      VCC                   Power Supply   (+3.3V)                                                     IDE VCC

21      GND                   Ground                                                                                IDE GND

22      VCC                   Power Supply   (+3.3V)             VCC                                IDE VCC

23      GND                  Ground                                         GND                                IDE GND

24      GCW#               Write/Clock    (C gpio 3)           SPI SCK Clock               IDE /WR

25      GCR#                Read           (C gpio 2)                                                         IDE /OE

26      GCO                  Serial Output  (C gpio 0)           SPI MOSI                        IDE /CS0

27      GCI                    Serial Input   (C gpio 7)             SPI MISO

28      GCC#                Command/Data   (C gpio 1)                                             IDE /CS1

29      SEL#                 HW Slot Select (mb out)           CS# (Chip Select)

(no real hardware were made with this yet, so tweaks are imminent also)

Petr

[7alken]

hi, some 3 days brainstorming about enhancing VGARC by 256 colors final programmable LUT, 8 tilesets, each with own ink/paper pallete, modifying charsets to "only" 6x8 (as is Sinclar QL font rendered into bitmap framebuffer - it looks and feels cool in theirs "ED" quick editor of SBasic, actually "the shell" of QL ... coolest thing I missed since 1986 when I got Atari 800XL, while ultracheap QLs were laid in western shops, but embargo on 68K prevented them to go here ...)

Its actually quite wild, ... and then I found Zeal8bit and what that guy did ... okok; forced me to think even more about BEST tile-based-gui and syntax coloring editor possible even on ANY 8bit old boy;

and I also randomly found some "SAA7105H" - its TV chip from Phillips, final stage generating also probably quite decent PAL/NTSC, but allowing also VGA output pass-through form pallete byte-index stream (format 5), so allowing best quality true-color final stage of digital video encoding, going from simpler CPLD logic ... I hope; but I dont know, if you met this somewhere?? it can probably serve as decent quality TV out, its programmable as hell, in fact, ... in fact ... too much  ))) surprise ...

so my raw brainstorming is attached ... my fault is that when I am focused to something, then someting interesting occurst and starts more and more sparks in head; so context switch happens .........

[7alken]

btw that nice screen fot of QL is this on the left ... obviously single thing extremelly ugly on Basic are line nubers, but be sure, that SBasic of SMSQ/E doesn't need them at all (no gotos, noting), so they can be stripped for editing, and while QL lists weir keywords as "DEFine PROCedure", they can be entered or in soruce as lowercase combos as "defproc" ... I dont like also uppercases, may be on constants only, but almost any program can be edited without line numbers, so easy reorganizing code, moving things, easy ... and primitively this can be rendered with generated line numbers and loaded ... (I did this while modifying QL Commander almost year ago - while Andrew, author compiles this into native code, as it targets slower real hardware, SMSQ/E SBasic is so much faster, that they even dont recommneded to compile it ...and on FAST emulators its FAST as hell, for me it behaves like hardware, like embedded thing ... but ya, this is core-i7 blah, blah ... and emulator at full speed ... I was able to modify entire QL commander source to linenumber-less lowercase, compact keywords version (source), with modified REM arks to "apostrophe" to be syntax color editble by SciTE/scintilla-based editor with added keywords (lots of them, its flat, no namespaces, keywords count as in forth ....), simply I did transpilers back and forth from source to loadable code ... and even integrated direct executing/loading from source form inside that double-pane Norton or MC-like file commander, which is MUST for me for decades ... anywhere, so on windows I have Ghisler TotalCommander (paid for decades)) ...

so this is how QL font looks :-)

[7alken]

as demo of look&feel of semantic coloring and simplified "lsb" version of QL SBasic, there is my almost manually tweaked QL Commander source (older version, Andrew has new thing, switching from Qliberator to TurboBasic compiler, with some caveats, but as I sed, I dont compile this in fast QPC2 and I also even stripped the integer variables suffix % everywhere, as SMSQ/E SBasic is faster on floating point vars, and having

the % suffix everywhere distracts readability of code a lot (sure regular $ on strings is mandatory) plus ":" multicommand lines were linearized mostly, as the linear top-down code is far more readable (you know this from asm, ya ... except original CP/M source where it was also used, more instructions per line ...) - for desktop editing/previewing of any code I still (for decades) use heavily configured SciTE/scintilla and for LSB extension, this is mapped to MS VB lexer (detecting apostrophe as comment, so this was done in BAS/LSB primitive transpiling too) I also edited proper indenatation - in QL era, this was wasting memory by additional spaces, today its not so important, even when live executing from non compiled source code (original SuperBasic had quite slow implementation, they were hurry to release... but Tony Tebby's QJUMP in SMSQ optimized almost everything drastically very soon...) 

after this conversion of BAS to LSB (my own name of simplified thing, although there WAS already historical SSB, more complex transpiler, I dint knew about that when trying my experiments ... so it was later named LSB ... this has very light linkage to hamradio modulations :-) I also chated with machine about possible analysis of the QLC source in LSB form (she doesnt know almost nothing about this cooked thing, but was able to generate python script with my assistance) - so it produced some usage statistics of user declared defproc/deffn and left undeclared internal SBasic functions - some results was added to SciTE VB-lexer congif to show more syntax coloring on kewwords for readability ...

so attached is example qlxc.lsb (original copyright of QLC is of course Andrew) and SciTE semantic syntax coloring I use (of course colors used are totally personal thing and many these days preffer "night mode" inverted view - actually, I dont; I was happy when "positive" paper-like view com with GUIs in early nineties ... as when you read a lot from paper and then must "switch eyes context" to inverted black paper, this is quite complex for brain ... AND the semantic coloring has also VERY retro reason, as my colors selected (and bold black for keywords) was related to inkjet colors usage - mostly black and VERY few of colors, due to price of inks ... today, I dont print anything but 20yrs ago it was very often ... then using fluorescent markers on sections of code and hand made notes into soruce .... you know, learning from others...)

in relation to QL UI usage, they heavily use channels for window# panes, open#/close#/ink#/paper#/cls#/print# ... here in source I glued # to keywords because of syntax coloring - # actually belongs to channel number, of course ...  this is heavily coupled to defined screen size, it is of cours nothing related to MVC/MVVM or so separating GUI "views" definition from "controller" - this was not used at that time, sure ... despite me implementing something like this in early nineties inside PC-FAND relational dbms (originated in fact at CP/M machines, using TB compiler) which was absolutely futuristic declarative system scripted with interpreted pascal - there I used single controller for more views on single data model, reacting on UI events for actions ... this "fandows" historical thing is totally separate story, though ...)

in case we will be able to define one unified graphics adapter screen/text resolution, this cheap oldschool approach can be still portable, although I would like to see some templated declarative views support also ... ))

this is reason why my wish/dream to have fast tiled fonts gui engine for fast color editor/console possible anywhere - sure it can have added cheaper adm3a terminal access too, but tiled graphics is fastest thing how to do this with as low number of CPU cycles possible ....

so, end of historic retro fusion with brainstorming today ))

Petr

[7alken]

ohh, I forgot pictures how for example QPC2 emulator of SMSQ/E looks - this is not of course tiled gui, they rendered everything, but it looks quite nice in 256colors mode (Aurora at least at that time)
its pointer/mouse driven but as this "PE pointer environment" was added before SMSQ/E was born (and it integrates it), apps were mostly keyboard driven by design, even with GUI, this is quite cool too;

also here is example how QLCommander looks, this is executed from LSB to BAS primitive transpilalation (basically, added line numbers, replacer apostrophes by REMark ...) ... QLC at that time was NOT
GUI SMSQ/E aware mostly, its raw text app, so it launches in upper left corner of desktop and looks different from this form of GUI - its quite hard to follow ocmplete history how these things were done

in QL world, and when, but SMSQ/E integrated most crucial things into single package (not possible at that time on nare bone QLs, though, it all required accelarator boards with 68020/030/040
(bus connector is inside QL, there was squared area of 100x100 mm free to insert something ...

[7alken]

back to chips ...

of course, these dual-port srams are extremely expensive and unobtainable almost, the more 3V3 ... this turned into FPGA in fact;
while is probably(?) possible to use regular cheap SRAMs with smaller CPLD and move that synced dual-port logic there ... its still question of complexity; (challenge);
what Zeal8bit uses (I didnt knew anyting about this few days ago ...) is Lattice FPGA LFE5U-25F-6BG256 - and his board is in fact quite generic and adapted to Z80 bus already;
not sire if he is able/willing to share internals - when I investigated Verilog tools, anything from Lattice seemed to be less friendly, open-source is only for iCE40 support;

for those who are afraid of CPLD/FPGA ... it can be quite similar to KiCad schematic drawing and seeking the chips - for simple cases, you place gates, and flip-flops
and registers and then the tool turns this into code for CPLD/FPGA (early CPLD were faster than FPGA, and simpler, programmed using internal flash, having stronger
metallic interconnection matrix than early FPGA, so Altera Max-II goes up to 300MHz (well, moving more challenges to 6+ layer designs for BGA, expecting max SDRAM
133MHz anyway ... but now with JLCPCB prototyping, they even include "filled via-in-pad", so for older BGA with pitch down to 0.8mm its probably possible to play with it ...;

but placing single FPGA with embedded sram large enough is cool idea, sure; and there is not much around it, Zeal8bit has also audio out and amplifier and knob etc etc;
it seems to be ready at 5V Z80 bus, even for total rewrite its internals (???) ... well, I may be cheeky enough to adapt this thing back to 3V3 with another set of 74lvc4245(?)

but, wait ... his first prototypes were using Altera EP4C having 32kB sram inisde, so well, we fit this there, using old free Quartus  ... ??
(it seems it is more power hungry, by the large capacitors, but ... okay)

I again went wild with brainstorming, excuse me this here, ... wishing to imagine the cheapest 7xtgv ))
Petr

[7alken]

okay, re-reading again VGARC specs, Bill inserts 2 blank lines after each text row to extend fonts real space to 7x8 (having single pixel as horizontal character gap),
good for text but not for tiled GUI; ... https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:vgarc1:vgarc1home

it means that his VGA really renders 480 lines * 512 pixels now - its question of size of watchable chars on small LCD, cant imagine smallest chars readable, but can imagine mode of 2x

scaling for on demand area visible on screen (imagine for example, mouse buttons (or kbd "win"?) controlling that switching - full tinies desktop vs focused 2x area / say, 4 segments ... ??)
with virtual full desktop of 96x60 (using 6x8 chars - I know I am fascinated by the QL font size ... complicating the easier 8x8 by 6x8 ...)
but such size already goes over 16kB SRAM (those dual-ports are hard to get, there are some cypress vbga100 - these are tiny, 0.5pitch, grrr - but you can see ppl soldering this too,

in fact as its smaller, it can get easier heat-up bottom/up? - but its risky??...) .... but that Altera EP4C FPGA (in familiar 17x17mm bga256, the same as Max-II CPLD) are here, I have few too,
was in fact searching just around that sexy 17x17mm bga256 package everything supported by older Quartus ... and this IS possible, up to Cyclone-IV; ... so okay, theoretically; 

(crucial note - ya, I am still "fabless dreaming center", imagining testing in FLEX-ZIFed THT ball-pads etc etc - up to successfull soldering of the B(ga)easts ... without friend Roentgen device)

say, 96x60 (without 2 blank lines between text lines) means 5760 chars per screen, so digitally rounded = 8192, plus other such buffer for "attributes", okay ... we have now only 3bits
to select fontset/tileset (I used the term tileset, although in is more from games/sprites world ... but hope we all understand;) by rearranging the attribs to allow 4bits for fontsets

selection, we must reduce some colors, 8 foreground inks seems to be mandatory, but papers/backgrouds? - there CAN be only 4, it seems;
switching fontsets (EACH has its own ink/paper palettes(!), so its huge selection of colored tiles for screen) looks more flexible when we was forced to double videoram to 32kB anyway;

interesting thing is that Zeal8bit WEB emulator including screen.js (peeked already into code, never was friend of JS, btw ...but this is clean, free of weirdo surprises, it looks like C, okay;
there is bit of jquery and for this "QL textmode", all the games/sprites/tilesets can be omitted and it can be probably possible to model something using this; 

although, they also have in private beta testing NATIVE emulator for entire system/video, using GPU shaders etc etc - this is far over my head, ... but they are doing something interesting, ya )))

(must admit here I pulled the trigger for the complete package ... while having already in tindie cart set of RCBus parts ... you know, I was long time not sure WHAT exactly may be useful

for me best ...  as I want to build Bills VGARC also as-is, on RCBus (clash of IO $00-$0F with RomWBW? discussion about 16bit IO ports?)
 - question here is if go to exact cards, or at source/kicad level to redraw own layouts - dont get me wrong - I WANT to have some RCBus based testbed too here ...
even new 80pin, as the cards are then more stable, although hard to pull (looking at the imagined 7xmem/7xmod "tower" in OT...)

regarding to Zeal8bit - I found this thing while searching for MMU info; and it has 4x 16kB similar to Zeta SBC 2 (I read also entire retrobrew of Sergeys original yesterday), but, not going into

details in Zeal schematics, it seems the guy is also "reading back" the registers, where I dont understand this complexity - Z2 is output only, reading back is easy when you store value both to

(cache) register in memory AND to output only IO (reading back from memory to fetch the actual state... or not?) ... AND he (Zeal) knows well, that his system doesn't have CTC, no fast

interrupts timer, and he bitbangs UART, also PS/2; but expects also some "smarter" interfaces on his user port ... ya, its not modular thing; everything probably is concentrated around that

advanced FPGA video card design, understood; ... okay; but they have also MC-like commander clone already in C ... so, excuse me, I was catched by that also )) ... 

peace, as always; :-)
Petr

[Bill Shen]

VGARC is supported by RomWBW, you just have to turn off the front panel auto detect in RomWBW configuration.

4Kx8 Dual port RAM is fairly cheap, my last purchase from UTsource a year or so ago was $2.50 each.  Larger dual port RAM are quite expensive, I agree.  Earlier version of VGARC support 80 column x 56 lines and does not insert 2 blank lines for each row of characters, but it needed two 4K dual port RAM.  The design is still here,

https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:vgarc

There is an existing CPLD design to eliminate the two blank lines in VGARC, but the screen shrunk to 384 lines.  I don’t have enough logic in CPLD to software toggle between the two modes.

I have worked on 640x480 graphic display with 16 colors, but the memory demand is high and it takes a couple seconds to update the screen.  It seems a bad fit for 8-bit retro computers.

Bill

[7alken]

thanks for reply Bill, ... you know, I am still considering that 640x480 but ONLY using TILES (so now cca 2x5kB chars/attrs max, not graphic framebuffer), with more complex logic to "traverse" by attributes/fontsets/palletes (and 2 "brightness bits"  on crippled 6x8/8x8 characters shown, to finally obtain single final pixel color parallel byte-index at CPLD output (ITU stream needs some start/stop sequence per line for target SAA7405H, where is RGB LUT of 256 true-colors defined), so this SAA7105 may simplify some logic, does 24bit RGB on proper (10bit!) DACs, so saves pins on CPLD too and can even generate PAL/NTSC from this, although it must be uglier on old TV monitors, than on VGA - sure today, external VGA-HDMI box mostly for me here ...) - I dont know how/if this slightly newer PAL/NTSC encoder can generate cleaner signal against some older TI TMS91xx or Yamahas V99xx ... I found SAA7105H almost randomly, was curious and peeking into datasheet (before that it was SAA7129, but it has not that 256 color LUT, no direct single index byte per pixel (format 5) mode, only 2byte YCrCb - it was all designed to play DVD content, allowing OSD semi-transparent menu, also Teletext and some patented DRM - those things not useful at all ...)

ironically, 6 months ago,  I had already on desk also that usblaster and epm240 cheap board you are using also, and there is similar cheap one with Cyclone-II, both prepared for first testing in Quartus; but then I was disabled by that ugly pain, unable to do anything, grrrr .... bte, are you using also Quartus/Verilog or some more effective raw way to do equations??

[7alken]

btw, Zeal 8bit video uses this free BigBlue terminal VGA font in his 8x12 raster ... I know I am here still almost obsessed by "QL-like 6x8 (or 5x8, they dont count the gap)" (not sure about its licensing though, true) and it is flying through my head since I had experience with QL aka SMSQ/E in emulators ... I can imagine now how practical it can be to have fontsets of 128 these 6x8 (with the paper/ink brightness "modifiers encoded in bit7, bit6 of 8x8, per each character line ... this was only QUICK immediate idea how to solve impossibility to draw "bold" - alternative are 2 separate palletes for paper/ink there also - again, cant imagine, impact, possibilities, nothing ... without some simulation, playing with it ... (that Zeal web emu source CAN be usefull, I am sure)
https://int10h.org/blog/2015/12/bigblue-terminal-oldschool-fixed-width-font/

its question how (im)practical the 6x8 raster can be while defining some special chars or windowing "glyphs", but I at least feel its compact to be used as "window frame", "menu" ... things like that;

not much experience with things like "ncurses" also, truth...

this is something about QL "founts" (they almost strictly pronounce it this way) ... no fixed raster, they render anything into framebuffer;
https://dilwyn.theqlforum.com/fonts/index.html

Petr

[7alken]

umm, fact is this vertical spacing is in fact in total for raster 6x9, so ratio 0.6666 ... and that Zeal8bit text mode raster is 8x12 so ratio also 0.6666 ...
okay ... complications, slight only, with memory requirements for many fontsets ... okay; fact it here on modern display, it may look also nicer somehow antialiased too;

this QL native look has horizontal spacing 1/6th = 1px (6x9 raster, font is actually 5x7, so nothing licensable at least ... just basic raster LED/LCD text) 
but to rescale exactly this into 8x12 isn't for exact scaling of this "pixel-friendly" - but its actually far better than my  6x8 ... as this at least 1px vertical space IS needed;

ummm.... I am in trouble )) ... fact is, although weird, the raster of fontset could be 6x9, yet another complication to use this as linear bitmaps? already weird enough ... ??
( at least, maybe,  3x6 = 2x9 = 18x18 pixels using 3x2 chars as "hi-res graphics pane" minimal element ??  for fast bitmap render routine? )

... so we are at 128*9 byte per fontset, so 1152, rounded at 2048, so 16 fontsets = 32kB only for them + 2x 8 kb for chars/attrs ... so we are back with external SRAM
... and going back to CPLD only, with normal cheap single port async SRAM, synced for writes only during VBLANK anyway against visible screen updates artifacts ??

interesting; ... may be some similar "sans" custom font modeled first on that existing 8x12 Zeal emu ... definitely possible; but finally, as those 2 extra saved bits per

fontset character line as paper/ink brightness modifiers looks usefull(? - still focused primarily on the "syntax coloring editor features") ... it may end as 6x9;
and 2x scalling of entire screen on demand as focus for "foreground window" ... brainstorming again, excuse me ...

[7alken]

so, sure QL QPC2 emu on win is antialiased/blurred, - sQLux emu shows nicer 5x7 font bitmap, it looks even better ... 

having fontset raster at 6x9 though, we can have SVGA 800x600 pixelrate and 128x64 screen chars/attrs
 - with support of "on demand 2x scale" of ANY area on screen - so in fact, "virtual desktop", movable by SAA7150 hw pointer ... NO?, SAA7105 can't do SVGA ????
 - btw, to WHICH MAX pixelrate can be saa7105 pushed ?? - 128*64 chars means that NEAR SVGA 768x576 resolution
 - so 2 modes ?? - small font big desktop 128x64 (768x576 monitor only) and big 2x scalled font "single app" 64x32
 - or also PAL/NTSC mode 64x32 (384*288 pixelrate - handles this smaller saa7105 too?)
 - we are still crippling original VGARC 512x384 by our modified 6x9 font raster ...
 - problem is, these oldschool 5x7 fonts looks so cool with visible pixels - ya, here on big FHD HDMI LCD, true ...

[Bill Shen]

EPM240 is twice as big as EPM7128, so it is sufficient to generate VGA signals and font lookup and few bits of colors.  I used Quartus schematic for CPLD design.  My verilog skill has deteriorated over 20 years of inaction; Quartus schematic seems more efficient than its native verilog synthesizer, anyway.

Bill

[7alken]

ya, thanks Bill, understood; I expected compiler inefficiencies (its nice playfield for anyone far more experienced (you ALL), though), so rather seeked more these 1170/2210 variants (some cheap sources, cant imagine here too much demand so remarking, who needs this today?), which lead to that bga256 obsession also, they look cool, no way to bend tiny 0.5mm legs also; 

btw, todays night shift sparked yet another simplification of 7xsys, so MkII was born, slightly confidential, again abusing something, but potentially far simpler/cheaper/easier to build;
this simply needs prototypes to be realized ASAP ... ya; ... all of my cheeky ideas came from YOURs knowledge and retrobrew pages ... "not because its easy, but because its hard" ))
P.

[7alken]

btw, that "slight confidentiality" )) is abused DDR2 SODIM-200 larger 160/80pin part and holding the module flat "somehow" at the center of edge only;
probably some flexible enough 3D-printed case/base with screws for heights up to 51mm (20,5mm half?)
(level of "creative damaging" of the original sodimm is up to the user ...)

[7alken]

something like this ... crippled DDR2 SODIMM socket, cheapest one - 80pins in line single-sided, or abuse as 80pin dual-side ... something ))
(soldering this using wick having proper mask cant be so complicated...)

- pins fit under 51mm prototype size, side guides are just slightly below 51mm too ... good;

P.

[7alken]

hi, still on drawing board here; more consulatations with Lyra also about timimngs/edges/ringing, series resistors etc, hopes that this can go up to 133MHz though ...
now is closest probably Dragonball 68ez328 in bga with some samsung MCP beast with NOR Flash and pseudo SRAM ... async UtRAM weirdo ))
will try this as standalone PCB over that uart bootstrap, ufff, fingers Xed all the time ... ))
(btw, I would be glad to consult anything here too, but don't want to distract experts with anything near to nonsenses ... that chats are LONG ...)
P.

[7alken]

btw, damage to the nice DDR2 sodimm socket on the central board is not necessary ... the short part can be used for anything custom too, but better as separate thing to stay in 51mm limit :-)

[7alken]

hi all again, while deeply thinking some weeks ago about "7xtgv TUI graphics processor", I also found recently the development around pico9918/F18a and just now few days I was reading entire Troys story on AtariAge; ...very nice; so, I also realized I still don't know TI VDPs well (9918...), never used them, never had any systems with them (nor John Winans Z80Retro!- never built the VDP board, only the base system ...) but I studied datasheets up to V9938/V9958 (expensive beasts in 64pin shrink-DIP) and wanted to do something with them, ... but once I saw Sinclair QL - QPC2 emulator and how theirs default "LCD" 5x7 font looks on display, I was hooked into this (which obviously has ugly big spacing using 8x8 chars - almost no 8x8px based home computers were good at "nice looking raster text - spacing") - I only recently realized that TI VDPs text modes are using this 6x8 raster also (throwing away 2px at right from fontset) plus T80 mode is using this too - in fact, for TUI, I am more friend of more "rectangular" xy ratio, so that T40 (perhaps also double line count T80 is the limit, while I also ended up with 128x64 drastic edge dreaming...) and/or even something DOWN TO like T20 / T10 for zooming-up areas of big "desktop" on demand, or using this limited/zoomed area on very tiny TFT/IPS displays, where hi-res text is unreadable anyway, even if the displays ARE capable of hi-res graphics (no text/palletes controllers though, only DMA-ing framebuffer at some refresh rate, some latest controller even don't have on chip VRAM also ... so expecting ONLY receiving FAST digital RGB/sync in MIPI style, okay) ... BUT so, there is now the pico9918/F18a .... not FPGA based, but VERY capable in form of MCU (and its quite basic one, overclocked here though also) ... if I remember, I always believed years ago that MCU is good alternative to FAR more complex FPGA approach... honestly; and, studying now Troys pico9918 hw, its firmware is in fact also "tweakable" towards dreamed 7xtgv features, and it looks even easier than to try to provide anything game-related ... not much  interest at all here; so, now, although its out-of-the box usage, I got latest pico9918 and have plan to hook it first to "plain Arduino" (and use already tested by me TBA TinyBasicArduino (try to integrate that), enhanced by author a lot during few years back since I tested it and even tried to split its source to smaller modules - he did it obviously too and pushed it forward - Troy recently added to pico9918 also configurator (platform dependent) compiled by another cool project - CVBasic ... in fact this thing is somehow close to my ASLIX dreams (ASLIX wants to be more C-ish and even simpler, but CVbasic is good proof of features for such tiny thing - and it is COMPILER(!!), for z80/6502/9900 till now ... yet; )) ... so, ya, another set of brainstorming and documenting the process here, even for myself ... Lyra helps too, but in the areas of QL and 9918, she is not very well trained ... but it is helping a lot anyway, so far so good (kudos gpt5) ... what I am STILL curious though is, if stock 9918 or even F18A T40 and T80 text modes are (both) capable of multicolor char attributes, or if its only G32+ thing (almost nobody mentions this, not yet deep dive into F18a datasheets) ... this is where I want to play with pico9918 even if it will end in modifying firmware out of F18A extensions - may be extending it far more to support text/glyphs for TUI ... IF I will be able to do so time-wise, not sure ... but anyways, somebody sometimes can try it too ... IF we all on the planet are not tied only to games but also to some learning/teaching of manual asm-like coding on tiny low-power devices, at least for fun ... (and I don't treat any asm-like coding as some kind of "superability for supercapable artificial elites" or so ... also, sad thing is: it is targeting mostly only single processor line .... mostly, except using VMEX; ...everything in-progress in-parallel  ))))))) cheers

so, kudos to CVbasic nanochess guy  and Troy behind great pico9918/F18a - all is on AtariAge forum too :-)
https://github.com/visrealm/CVBasic

(F18a compatibility things can be tested with js99er or classic99 TI99/4a emulators)

-Petr

[7alken]

hi all again, as Steve RCBus set is now ordered together with Sergey Z80-512K pcb and cpld (for planned 3V3 torture of it all...), here I have to share some more consulting with Lyra about some things not related directly only to RCBus and Z80, so posting rather here... I feel its quite lot of interesting info asked for history of logic gates, technology around fast vs low-power (and returning metal-gate again ... quite new to me that happened around 2007 with 45nm ...interesting) ... also something about tiny connectors/cables for CPLD JTAG-chaining and integrated debug port having both JTAG and also UART RXTX, big wish ... + also something bout I2C (retro as hell, invented by philips for TVs in 1982)

I2C extenders 23017 vs 23018
https://chatgpt.com/share/68c74fbc-1310-8000-8b89-1104c9074837

alternatives fo hc688 and ac521, address decoding (thanks Mark for note about 521)
https://chatgpt.com/share/68c66564-0990-8000-a209-7b9065e34f43

something around 16/32 data bus mux to access large SRAMs on (new) DIP32+16 spec
https://chatgpt.com/share/68c75026-e888-8000-9212-50037d1705d5

logic technology history down to DTL or so ....
https://chatgpt.com/share/68c750ce-f088-8000-847c-2f2a088d1c31

here it started about 688 comparator, but ended also with 7xsys debug (cpld jtag+uart rxtx) tiny connectors and cables...
https://chatgpt.com/share/68c751cd-c90c-8000-8ce3-968b256fefe8

[7alken]

hehe, here I am peeking into history of AR magazine and found probably first mention of digital logic at 3V3 ever ... (at least as far as I know) ... mr L. Winter (or local ARDF sport icon, and I remember him from childrens ham camps - he in fact brought there first PMI-80 computer (like KIM-1 with mhb8080) where I wrote on monitor by hex code of  player of simple bit-bang music to connected telephone speaker - he was quite surprised ... I had 11yrs or so) working on digital keyer for ARDF transmitter, torturing 5V TTL logic down to reliable(!) 3V3 (because of using flat 4.5V 3-cell battery without Zener (of course no LDOs) for full discharge range ... just random thing here, cool find ))

[7alken]

this thread is quite wide in topics, but all is realated to 7xsys/7xmod/7xmem and 3V3 experiments, so as DIP32+16 spec finalizes, I peeked more into DDR1/2 sodimm drawings and finally its clear where is difference, as both are 0.6mm pitch, okay, but DDR2 has 1mm narrower the wide 80pin part, the key is closer to the center and ONLY in this DDR2 case then width of 7xmod/7xmem PCB can stay under 51mm JLCPCB limits ... (for more complex multilayer/via-in-pad etc prototypes) so, here is update which can probably be used now, even in Sergeys Z80-512K flying to here already, I have the CPU and PLCC32 to DIP32 adapter for flash, will get the 3V3 CPLD to copy content there etc, but will also test some alternative SRAM chips on that DIP32+16 adapter/module, including so called FlexZIF for BGA48/90 - this MUST be tested and I believe in it a lot, although its linked more to larger processors as 16/32bit as Dragonball 68ez328 (bga144) and dreamy PPC like mpc823e (bga256) and some other spacey thing; ... and also I re-noticed Bill Shens G8PP and GRC projects, cool too; but overlooked probably as I focused on 3V3 and heavily on altera max3000 (5V tolerant IO) and max-II (3V3 max, but tweakable carefully too) - as sure, want to try also some old NMOS things still on 5V, and there are also some VDP boards (RCBus) done for 5V of course (and zeal8bit VDP) - for these some generic RCBus to 3V3 adapter can be done, will see

So here are drawings of DIP32+16 as-is defined now, time to go back to KiCad and try also ASAP the "freerouting" autorouter, how its useable for first layouts. Curiosity.
(having split things into modules can be easier for autorouter too, I hope - following Bill Shen approach heavily, yes - and betting on CPLD flexibility too, to correct things using Quartus)