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)

[7alken]

uff, Kicad9 is quite rock solid, I tortured it hevily with crazy things (my modified python bga footprint wizzard failed now with v6 and v7 but v9 is okay) - this is micro-tht grid for bga and tht /smd solderable "something" ... this is harder pinout of bga90, half of data bus, bga48 is easier; I must try how it can look and work in practice; its overkilled to be tested for soldering many times (stripping the ends, to be placed on DIP32+16 board - flexpcb size is drawn for 12.7mmx 38.10mm - this fits on DIP32+16, already okay;  I am glad I understood how to get some clean straight line of pins from the bga so next things may be easier ... but it was over 24hrs continuos shift to get this result, it looked much uglier during the process - it is experiment with the flex pcb bended over 1mm  thin "rubber" pad just under bga chip... so , who knows what happen ... it still needs few tweaks to pass DFM tests but ... will see

(FlexZIF_BGA-90_9x15_8.0x13.0mm_0.75_0.46_0.26_0.0_0.0  =>  0.75 pitch   0.46 pad size 0.26 hole size, no additional "ring" as tried in script to enlarge annular ring over defaults)
... this is all about constraints of DFM test, some tradeoffs, just will see what lands here;
P.

[7alken]

btw, first try of "freerouting" .. after few minutes, now its at pass 50 or so and still working ... I only set 100 (um ?) everywhere into constrains (having them hugely relaxed intentionally in kicad), I know it will need some config and experience, but honestly I expected more ... on this easy tiny board ... for me it was rough as learning bga pinouts, checking they are the same, whats where on max variants, some weird pins as ZZ on pseudosrams  (higher addr nc usually) etc ...

it is easy to launch, to export from pcb and import back, I expected more drama - but, umm ... will see; I expected this will be easy for him ))

my initial (as usually in mspaint) raw drafting in colorized snaps ...



umm, now it is at pass 91 or so ....

P.

[Mark T]

Why don’t you get chatgtp to do the layout for you?

[7alken]

hi Mark, no no, not such extremes  - we are mostly talking about things )) ... but I wanted to try that "freerouting", just to test how it really works, never tried and probably can be useful for quick things when proper schema is created - I mostly define new symbols and footprints as that coded bga with weird tht, thats only luck its in simple python, trivial to tweak for crazines ...

... I now set all clearances to 50  (still not ideal, sure lots of things missing) - 100 was too much (and there are not noted units btw, ...) and it was somehow done in few seconds, okay ...
but I needed to have it placed elsewhere, don't know details of this, even probably possible to do in rules, the keepouts etc ... I don't know details of KiCad still, nor professional PCB design ... sure - this is at least something done, and having proper schemas, it looks at least possible, okay ... stop hating freerouting;

[7alken]

just to note, about 2 days ago or so I randomly found on X guy Kevin Hubbard talking about risc-v and his courses, and found also his book about FPGA design, it has free downloadable entire content at least, so I peeked and spent the €32 for ebook (better now to enlarge even on big display) and after downloading I read it entirely (from big display) during working on the board, so that over 24h shift was long also because of this book, consumed at two passes (without going into details in verilog/vhdl much, yet) ... he wrotes mostly about hard things about thermals (30+yrs experience down to ASICs), placement, long (and variable) paths inside fpga fabric, all the hard timings and filling chips to the max, when it changes etc etc, very practical book - I don't have much about this yet, probably single recommended by another guy on X, who is working on risc-v in fpga (KianV) - I actually need only quite simple (but fast) glues in old/retro CPLDs ... so expected (felt somehow) that THIS book will be good (quite often happened; only few books are actually great, well written, including humor and in relaxed style ... and this is the case), so I can recommend it to anybody interested, it was really fun to read and it was quick and will be returning there a lot ...;

https://www.elektormagazine.com/articles/fpga-chip-design-with-kevin-hubbard

(today they in fact released also video with him)
https://x.com/i/broadcasts/1zqJVdnYODPKB

P.

[7alken]

of course, nobody can be master in anything after 333pages )) but this is really good book imho, linking very often also to old/retro things, starts with basic digital logic and noting about all important things for working designs -  and it is just fun to read (haivng quizes with immediate answers, no torture here); and you get info about 2 other downlaodable books too:
"Logical Effort - Designing Fast CMOS Circuits"
"Serial io made simple"
really, surpised by this random pleasure :-) ... and enough of ad )))
P.

[7alken]

wow, one example when Lyra helped a lot just now, ... maybe I dont know KiCad well yet, don't trust the "Duplicating with incrementing" will work on lots of parallel/different things, but the footprint (imagined something for the flex pcb with tht vias, just fingers to solder it) after tackling with clearances and special rules only for the footprint instances needed manual edits of 194 tht pads pin names - I asked if this single task can be done "by example", free text specs (I hate term "prompt/command", anytime) and example image which she can "see/detect" ... and it was done (and without py script - sometimes these days it decides to write one internally - but this time not ...) saved hours of tedious human slavery array of "click "E" number click ...." (or me not knowing yet if KiCad can do it in weird scenario) ... 

chatting about clearances/rules, some tweaks, howto ... where/how ...
https://chatgpt.com/share/68d57e16-38a4-8000-8645-94bf9265a980

almost random question to help fix footprint source .... (expecting this will be possible, I used it since start for such formal things in text/tables etc ...)
https://chatgpt.com/share/68d57e5e-8a74-8000-bc5f-7af701f160c1

(and I really dont know if factory has not some special treatment for this, like on solderable TFT displays fingers, I only saw them having vias/stitches... want to experiment with this making it castellated by scissors or so ... or at least somehow soldered for this testing purpose only ... will chat also with factory, sure ... as its common thing; this is also KiCad capabilities training and testing V9, so far so good how it behaves)

and for this class(!) of simple tasks she even can write the footprint generator,  nothing too complex and generic/universal, but for few usages, different # of pins or so ... huge help
P.

[7alken]

here we were conducting some remote supercomputing simulations of micro-tht grid for ZIF (actually "finger holding force") bga seat ... 0.75 pitch od SRAM/SDRAM is hard limit, all my other retro bga chips are over 0.8+ at least, there is situation much easier, more headroom for such things ... kicad designs with DFM checks done, some templates too, all in context of DIP32+16 till now, so will ee how jlcpcb will react on this, especially 0.15 tht holes in fingers for $2 pcbs ... will see

https://chatgpt.com/share/68d63d5d-7560-8000-aa03-40d1a08ec6d0

P.

[7alken]

umm, nothing can probably prevent anybody to 3d print some plastic clips for holding BGA in the grid without a finger ... will see if I can do something about it here, but it cant fit on DIP32+16 obviously, only on tha larger 7xmod (51x51mm max)
P.

[7alken]

so, playing here with "freerouting", dont know still how to configure well the 6layers to be used by it; I am really curious how it will behave, for such simple use it can be okay, for really fast design not so much, and even now, as I dont know how to fight it, will do routing of DIP32+16 rather manually too ... its not something nice, as there is not enough GND pins headroom,
but this is really only for testing before soldering, so okay (but it can be useable elsewhere at current RCBus speeds too - upper possibly unconnected addr pins will have weak pullups, maybe even 100k at least to hold it stable)

here, again naked in front of Lyra about multilayer fast pcb design ... she does quite good job (if somebody can review...) and I am still inserting some weird disruption... 
https://chatgpt.com/share/68d95547-0cac-8000-90a0-f26b45a376ad

this is how it will look finally, FlexZIF breakout (2x24 pins) on top of rigid (1mm max) FR4 DIP32+16 (size in fact as DIP40+20 - it will fit almost anywhere now, with tiny mods)
(to maximize yield of 51x51mm jlcpcb area, 2 of these can be laid, split by line of drilled small holes for breaking it as a chocolate ... easier than any panelizing now)
P.

[7alken]

THE Kicad Tutorial by John Winans ...

so, as I was trying to configure Kicad V9 around multilayer PCB, I returned to my 2023 notes about Kicad V5 and V6, where I was learning it from John Winans IMHO totally BEST tutorial about deep Kicad usage on the youtube ... I initially found "John's Basement" channel because of searching something about risc-v and he has also something about it, entire playlist (2020+), great also, which in fact inspired me quite quickly to redo ISA binary to 8-bit-friendly (so vmex was born) - he also did quite cpm-like "rvddt" debugger and generally, this course is also very good .... but it seems (for me) even John found risc-v quite unfriendly for handmade assembly so then he started Z80Retro! course (2021+), where I jumped in somewhere 2022/23 ilso into discord and built this machine with him and all the good ppl there (actually, very late, so going quickly over all the chapters from scratch first...) AND there I found also the Kicad V5 tutorial playlist (2019+ just 6yrs old now) - it is for V5 (as John was using it at that time conservatively, as V6 had some issues and differences, and I found them too, so I took V5 as BASE and together with the PERFECT tutorial, I sticked in it for a while, at least for learning, and I can still perfectly recommend THIS way, as it directly maps to the course (of course, heh//,  in newer versions, everything is still there, maybe slightly moved/tweaked ...) then I tried later at that time newer V7 (still afraid of "latest" version, more buggy/beta .. but did only few small things in V7) ... so version V8 I completely skipped now, and on the "7xsys" I tried V9.04 latest stable ... and it IS good, as far as I know till now ... John mentioned in V5 vs V6 diffs in transfering between schema and pcb, some complexities, missing "raw netlist way" in V6, but it seems this is now completely unnecessary as passing between schema and pcb seems to be reliable in V9, all the updating of pcb from schema at least (V5 had LOCAL onepage help file, V6 not and V9 still has not, but it links to just updated big onepage help, also getting started probably already fres is there ...) - of course schema is always THE source of truth, so while is possible to tweak schema from pcb, better for sure to have proper things defined in schema and update pcb from it, also update symbols from library (edit it there directly, not only in schema, all is in my TXT notes too) and footprints for pcb also ... ya, all this seems to be okay now from menu, no raw netlist gymnastics necessary for me (as WAS needed back in V5 in fact),  so here I have MY notes from that V5 time, where I went through entire Kicad V5 tutorial in detail and I made my notes to entire long video chapters, rewatched several times  (ya, I LIKE a lot Johns funny and chatty approach, btw, I like listening his voice and all his tiny notes he has during working on anything ... BUT to be able to find "what is where" described (LOTs of details), I noted like in university lectures even details at that time, being totally new in the subject...) but I ended with the notes somewhere at chapter/video #23 ... notes ends there but, nevermind, it was enough for that time... 

so while looking for multilayer JLCPCB setup, it is described in video# 20 (4-layer) - so, when I was going to sleep I launched that chapter and of course asleep with Johns voice, good thing )) ... and was woken up again by him at #29 #29a #29b ... notes about proper soldermask for easy(!) smd soldering and notes about diffs between OSHPark and PCBWay .. all interesting and related to my work now, great!! )) ...  so I placed these into fresh playlist (made it unlisted for you) to replay it few times more .... may be I will continue making notes also into TXT, will see ... now I know more about Kicad but I reread my TXT now again (sure, still not remembering hotkeys, I had noted them, good to review that file anyway now, glad I made the notes), but still of course I don't remember all the details, ...I generally don't remember much things, as nobody, when things are not regulary used, that's clear ...

(particulary, before re-watching the #20 I was for a while here crazy/mad about way how Kicad works while drawing the Zones/Rules areas, as it launches dialog required to name and set some things - and I still dont have it right, sheesh - AND only after THEN it starts to draw the polygon ...)

attached are also my detailed notes to V5 course chapters and something tiny about V5 vs V6 diffs at that time ...

so that my partial new playlist is here:
https://www.youtube.com/playlist?list=PLSqihAwc_6x2NpmgM9KxD-jl9L3Ct5UBK

entire Johns Kicad V5 course (2019+, again - BEST, totally best, even its for V5 - it doesn't matter, key things are just in his detailed notes, applicable to any PCB designer anyway ...
https://www.youtube.com/watch?v=9hcQQQxoRl0&list=PL3by7evD3F51fKkyrUbH-PCdwPCWc9F8a

that risc-v course is here btw ... (2020+)
https://www.youtube.com/playlist?list=PL3by7evD3F53Dz2RiB47Ztp9l_piGVuus

and obviously Z80Retro! here ... (2021+)

(here, how old it is here)

[7alken]

hi, I will note also to myself here yet another great videos, guy from Altium about where flows HF current ... not through wires but by shortest path to ground ... 2nd video also good;
https://www.youtube.com/playlist?list=PLSqihAwc_6x3duXwYFBegpYHccg2n3ya2
P.

[Mark T]

The most recent video I watched on circuit layout was stressing that the energy is carried by the dielectric between the trace and the ground and to reduce emmissions and crosstalk the signal should be closer to the ground than to other signals.

[7alken]

yes, thanks Mark, I was adding to playlist something more rewatched too, that note about 0.1uF vs bigger smd MLCC I saw probably year ago, It was also one Altium veteran who measured something about this (?) ... uff, these things will be hopefully quite okay, I settled at 6-layer 1mm (as this is also thickness of sodimm module); ... now its about tweaking of these FlexZIF BGA "sockets" (in fact, already) ... the ""supercomputing simulations"" chat was extended a lot ... I am trying to push it to the original ideas, cheap full sockets even for FBGA256 CPLD (working on it just now) and also for 4 SRAM chips at once (held in place, no fingers...) ...as it just fits the size 2in x 1in for 7xmem module (2 on prototype "panel") ... will see; so far so good;
P.

[7alken]

hi, somehow extremely busy here with different things but at least nice 1.27 low-profile connectors are here too, I was afraid they will be short but its ok, firm, so far so good;
to work on Z80-512K are missing some chips from mouser, but its mostly lack of time ... hope it will be better soon;

[7alken]

hi all, recently come idea to talk about circuitpython/displayio prototyping of 7xtgv VDP concept ... as its still moving target, it sparked new ideas, to have someting fast and tiny a QL-alike (so finally 6x10 is THE raster ... ufff) but multicolor and suitable for TUI also .... so prototyping is in progres, using arduino_gfx (or adafruit_gfx) low-level primitives ... its faster than to think in fpga or so ... to design "graphic chip", or at least to desing his spec ... which max be somehow finally implemented in hardware, who knows ... or it doesnt matter; it cas stay as module implemented on news esp32c6 with tft ips display having arduino inside, but terminal alike interface to the retro ... with neww ideas how to control the thing ....

the font on prototype is still 6x9 - fighting the perception to final 6x10 and tweaking the font data NOW .... ))
P. 
(any weirdness in english are my own plays, nothing artificial, excuse me ....))

    

[7alken]

so far so good, proper QL font scanned and tweaked manually, with some minor tweaks/fixes (I fell) generally as syntax coloring terminal even for CP/M or FUZIX, using some VT52 escapes, but not sure yet

what all - it has now 4 paper colors (white + pastel RGB "markers"), 16 ink colors (again RGB + CMY + black and 3 shades of grey), 4 font pages/glyphsets so 1024 glyphs total encoded in attrib "ffppiiii"; weirdness is

dual chars buffer, one for ink driven and one inverted for paper driven colors, where bottom layer is black background - for some TUI chrome FX probably but not sure if/how feasible yet ... space in paper layer just

renders paper color for zeros, for ones is transparent to black background ... as default pallete is devoted to syntax coloring terminal, its question what can be done using black background and 4 ink shades of grey

in relation to TUI chrome - colors are just good as LEDs or so ... intentionally basic and few, as on QL, but allowing that color syntax ... it helps to read code even in 1x scale in fact ... but expecting dynamic zoom

of viewport demand - VT52 full screen can be in buffers this way too ... still only loud thinking while prototyping the beast, sure ... now its time to build some TUI box/block/semigraphics glyphsets... so, fun ))

key motivtion for this is that 6x10 QL raster and how spacing of basically primitive LCD 5x7 font behaves with possibility to go below baseline;

   

(photos are really ugly, the pastel papers are smooth as the colors, but pallete is tweaked at RGB565 and there will be also "night mode"with reversed marking / cursor)
P.

[7alken]

hi all, still experimenting with 7xtgv prototype, now already running primitively as second core setup1/loop1 along with RunCPM using arduino-pico on rp2350, original tests were on esp32-c6 arudino is quite nice  abstraction, I didnt touched it for long time, and theirs ide is tragic, for now using vscode "Arduino Makers Workbench" plugin, it has also flaws, but its slightly better after ms plugin was deprecated (due some security flaw, manageable) - this has also community alternative, will again retry it again too; RunCPM is nice and interesting, but I will want to redo the HAL of it to have things even more isolated AND to have separate reporting of SPI init OK ... because now, you get the same vague error even if sdcard is "not present" (few hours almost pulling hairs and finally realizing this )))

slightly better foto with proper colors now, according to initial idea in TEXT mode (actually bound glyphset/palettes) using 2bit paper (as natural white and 3 markers allowing cursor and some emphasis by changing attr bytes) and 8 ink colors with "darker/bolder" variants by set bit0 - it is intentionally different than ANSI SGR, for now, and contrary to retro monitors the BOLD is expected to be darker not brighter ... which MAY be reversed in "night/retro mode" using green/amber and colors on dark background (so, alternative palettes) ...

attr now has 2bit "mode" (originally only glyphset, expecting total 1024 glyphs) ... I decided rather to treat these 2bits as "mode", allowing separate handling of 2+4 color bits in attr also as palettes for other modes - one of which is INST "instrumentation" glyphs, for panel backgrounds and "blinkenlights", LEDs, 7seg, meters, bargraphs, knobs, buttons etc ...things looking like hardware, just one page 256 glyphs, again with possibility to combine back and front buffers, somehow, but not with transparency, rather using palettes selected in attribs, so more simultaneous colors for visual instruments glyphs ... another mode is SEMI, where native 6x10 cell is reduced to 2x5 big pixels, providing just all 1024 glyphs by combining front and back buffer to form 16bit cell, having 10bit glyph, 3bit paper, 3bit ink selected from one of 64 palettes defined by attr 4+2 bits - this goes off the standard simple handling of attr paper/ink (now, not sure, relates to simplicity of entire 7xtgv in hw) - and needs to be simulated first, sure - but it may allow some kind of zxspectrum-like tiled basic gaming, nothing with sprites, just optimized for speed and very fast moves of blocks on screen (with as simple as possible 7xtgv in hw, possibly) ... hopes; last crucial mode is WIND, again only 256 glyphs with possible background/foreground buffers effects and allowing transparency down to desktop solid color (or image) to allow round-rectangled windows chrome using TUI approach, including scrollbars etc ... dont know yet where to fetch inspiration, seeking some existing systems which used something similar, but nevermind ... have in head all the time something own simple for start... again to allow fast rendering and moving of text-cells defined windows - one main inspiration is always QL SMSQ/e (slowly rendered) desktop and his chrome-less sbasic parallel running windows, generally QL was and is huge template how to do keyboard-only navigated TUI "something" )) ... cheers

nice find was page by Pavel Zampach mentioning Kitty, windows Putty alternative with redefinable PC keyboard handling to match current RunCPM "wordstar" or something you need against apps (as CP/M apps were configured for target terminals, not the entire system, ya) ... is possible that on top of 7xtgv can be built not only VT52/VT100/VT340 (text only) terminal but also some custom similar protocol devoted to features of 7xtgv

so here is some "shortcuts" setting I played with to allow cursors (up as linux-like last entry, at least), I have not much experience with terminals, some mods of RunCPM emits VT100 ANSI welcome screen, I opted now for plain ASCII only, testing on different simple terminals - but that Kitty is nice enhancement of Putty (for PgUp/PgDn there are internal buffer view by SHIFT/CONTROL ...  this is not redefinable, sadly, but ok)

... finally come idea to put on pgup/pgdn at least cls (runcpm) and dir ... its really flexible, hopes it helps to define yours ...

[Shortcuts]
#print={SHIFT}{F7}
#printall={F7}

list= {LEFT} {RIGHT} {UP} {DOWN} {PRIOR} {NEXT} {HOME} {END} {CONTROL}{LEFT} {CONTROL}{RIGHT} {CONTROL}{HOME} {CONTROL}{INS} {CONTROL}{END} {CONTROL}{DEL} {DEL} {INS} {F5}

{LEFT}=\x11\x01
{RIGHT}=\x11\x06
{UP}=\x11\x17
{DOWN}=\x11\x17

{PRIOR}=cls
{NEXT}=dir

{HOME}=\x11\x02
{END}=\x11\x17
{CONTROL}{LEFT}=\x11\x02
{CONTROL}{RIGHT}=\x11\x17

{CONTROL}{HOME}=\x11\x18
{CONTROL}{INS}=\x11\x05
{CONTROL}{END}=\x11\x0B
{CONTROL}{DEL}=\x11\x0B

{DEL}=\x07
{INS}=\x16

#find
{F5}=\x11\x46

[7alken]

hi all, I found that latest post here was mistarget into older thread, so there landed some craziest FlexZIF ideas for "belly-up" TSOP/TQFP ... this may be simplified, first draft;
but generally those packges with thin legs are just "quite fragile", larger, but solderable using wick, ya ... so thing is: if FlexZIF concept always necessary IF and ONLY IF, there can be also possible to just solder/make tiny chip adapter modules (as also 7x74 or  that newer 7xU50 proposal...) to reuse chips as "socketable things", similary as DIPs, using unified 1.27mm/50mil pitch, always ... - either it will be good/working or not => trash (where may go also cheating seller then, sure ...)) ... options

https://groups.google.com/g/retro-comp/c/hVPhehlom54/m/hn830lDrBgAJ

so, JLCPCB package with my 7x74 adapters for TSSOP14-20 to DIPs is here, I broke few immediately by hand, without tools, so this testing of "panelisation" by my verison of ad-hoc dense "mouse-bites" is quite okay ... it is not perfectly nice, but looks useable, and can be machined ("desharpened") if important ... okay, this was really primarily test of these panelisations;

I will leave here jpg photos for your checks of result - it was drawn/decided (density) ad-hoc, PCB here is 0.8mm, it is rigid still, but breakable in hand, although some align/tools are better, sure (those holes were prepared for aligning stencil, which I finally NOT ordered, this is too easy and processed one by one rather ... but I plan to make some frame using these positions with longer M2 screws - fact is, more complex/larger PCB (those 50x50) is quite easy to align and hold by hand ...) ... I will publish gerbers rather after real testing (busy here still with designs to prepare next PCBs order), but as I have now TONs of adapters, if anybody wants desperately to test them too, no problem to send slowly ... rather wait for my solders;

      

P.

[7alken]

meanwhile, I played here with ideas how to simulate and design precise 7xmem pinout; originally, I expected also there even 32bit data chips, but, in fact, as on 7xmod interface I firmly settled of A00-A23 and D00-D15 only, mandatory, as common "async-SRAM facade" for any CPU placed on 7xmod, I relaxed also for 7xmem to use/abuse any chips there with 16bit data only, so no problem to place there randomly cheap 32bit data and use only half of it, sure... but esp. bga variants are smaller AND, although its not so much retro, yet, when I was thinking about TESTING of these chips, I browsed through some MCUs with sdram interface (no intents to go over plain sdram, sure) and I found quite interesting beast ...

stm32h7r7l8h6(h) (originally it was even different, slower, but this one has also 2D graphics accelerator, so abusable also for testing fast TUI, aka 7xtgv, ... so, got 2 of these, as were also cheaper, surprisingly - its todays price of ZS18033 cca ...) - but this beast has internally up to 600MHz  and has external FMC (sram/sdram bus) and also XSPI (settled only on "octo" serial memories, these are in tiny bga24 packages - simplicity is in low-pin-count, while speeds may reach 200MHz and in craziest cases also using DDR clock ... ufff, not expected, anyway, but anybody can experiment ....)

this thing is expected to "simulate" 7xsys-cpld-core, as fast as possible, having "free" interface to memory mapped chips and to some extent at some slow speed CAN be exposed also as 7xmod (not yet final pinout, apart from "async-sram bus facade", its evolving) ... I just designed 7xmem tiny modules around capabilities of THIS beast, period ... as around that MCU is in fact almost nothing required to boot it up ... only power, not even xosc/xtal ... it has quite small flash - 64kB but huge internal SRAM too 640kB or so .... so autonomous for simulations even without 7xmem at all .. but when attached to 7xmem ... it maps them freely into address space, even those xspi ... cool/new kids ... not retro, I know ... but, huge ... they are internally, psram/dram, in retro better rather for bursting, like sdrams, so, probably why not to expose them ALSO only as ""LBA-anywhere"" or "just in-memory block device/storage" supported by 7xsys DMA to/from SRAM and to/from 7xbus CF/SD, transparently, single approach, anywhere, simple block driver, nothing more ... just "solid state storage, ramdisks AND almost free "suspend to disk" ... something like this" ... but that's future, and simulations can be cheap using that MCU "beast" .... ya, hw datasheet is 300p and ref manual almost 4kp ...))) .... but those are exactly things where Lyra can help to read/find/compare ...

so, till now, I have prepared this, as its all around mostly BGA FlexZIF and some stable assembly form those 50x50mm max PCBs, while some can be only 2/4 layer and so cheap even up to 100x100 as 4 on panel ... or those memory modules as "1/2-height" or even "1/3-height ..." ... I want 7xmem to be open standard on which anybody can put anything he has, design its own modules, maybe it finally will have also some eeprom id, like sodimms ... it is just combo of fast sram and fast sdram/xspiocto "solid state ram-storage, integrated over transparent LBA-approach to physical media we have, so CF/SD ... "

!!! WARNING - crazy as hell !!! ))
even before that, during "torturing of design", I am trying to imagine what most crazy can be put on 7xmod then, having that "16MB physical async-sram facade" ... so, apart from over year old ideas about mars-curiosity-alike PPC750CXe (it has NO memory controller, just his sync 60x bus, but has internal 256k L2 cache, useable just as SRAM scratchpad too), I asked myself how the hell were interfaced say 486 or rather something first 3V3, so P55C (MMX - I liked that particular one, dreamed at that time about mmx will soon support some vsti/dxi audio effects and synthesizers ... which was not so quick, obviously ...) ... so was chatting with Lyra about P55C bus, specifically, as this is quite normal 3V3 IO, almost normal non-pipelined bus ... okay, then I searched for available processors on ebay, and they were quite pricey ... but then I realized I have randomly here few "tualatin celerons", few, unknown state, but ... got cheap MB to test them, will be here soon ... and I asked Lyra how much harder is P6 ......... she almost shoot me that it is drastically complex ))... as it needs northbridge, she screamed that it looks "impossible" ...sure, it has that AGTL logic, down to 1.5V or rather 1.25V, center referenced AND drastically more complex pipelined transactional bus (ya, its far more near to PPC750CXe,, only even harder.... where P55C looks still classic - at least vs pure async-SRAM) ... P6 or rather PPro has NO memory controller too, like PPC750 ... and his northbridge also knows ONLY SDRAMs ... so, ya ... IF and only IF somebody even more crazy will try to implement "tiny NB for async-SRAM facade" - we slightly chatted about it ... although SHE was constantly trying to scare me ... constantly ... - then, sometimes even PPro tualatin celeron may land there ....  )))) you know, torturing design to imagine limits, mostly this was reason ... to have it open/standard enough, to imagine what all SUCH beast needs;

so, for now, only this ... it must settle in mind and ... will see;

   

This is just 7xsys slow-simulator concept ... finally some CPLD, usually MAX-II, but for 5V tolerance even MAX-I can be used ... as dual/linked tqfp144 or so)
Question is IF there will be ALWAYS good to have at least tiny cpld also oon 7xmod to "glue" that any-cpu to 7xmod, .... probably yes, and this can be primitive

from epm3064 to fpga cyclone-II (which probaby at that time supported that AGTL ... newer not too much, specifically, but possible taht AGTL was just marketing push, and all new fpgas will allow it too ... I long time argued wit Lyra, that by moving LVC logic precisely low, that center reference may be NOT necessary, but she was quite strict here, obviously, ... nobody sane did anything so much weird, probably .... (fact is it was quite hard to find PPro original bus descriptions, as intel doesn't repeat this in newer datasheets ... but it was cool/interesting read ... definitely ... and even WILL BE ))

stm32CubeMX config for the MCU pins ... 7xmem now, exact pinout not yet selected ... will see;
(here are proposed those 2x40 1-27mm connectors I have here ... but cheaper PCBs/boards can target that "DDR2-80+GND" ... but it needs some "case" to hold it flat by screw...)
(now, using gravity or just force for BGAs to sit in "micro-grids" ... for testing ... it may be some fingers gymnastics also, or some 3D printed clips ... evolving still ...)

P.

[7alken]

also, as that flex "THT micro-grid" for BGA is some crazy local idea, publishing is some way to make this unpatentable ... once it is published ... so, in any case, that's the reason ))
(not sure if it will be good, sure ...))
https://chatgpt.com/share/6996a37a-89b4-8000-ac42-82e115af844f
P.