
le seul ordinateur qui faisait traitement de texte et musculation. 💪🖥️
Retrouvez sa doc : retronik.silicium.org
#retrocomputing #heritage #toulouse
#vintagecomputer #geek #oldcomputer
Retrouvez sa doc : retronik.silicium.org
#retrocomputing #heritage #toulouse
#vintagecomputer #geek #oldcomputer
Retrouvez sa doc : retronik.silicium.org
#retrocomputing #heritage #toulouse
#vintagecomputer #geek #oldcomputer
Wee! I wrote a window manager for MP/M, four windows in the screen, dynamically resizeable, while program(s) are running.
Windows are virtually 24x80 "Heath H19" compatible, up to 30 x 90, so cursor ("curses") format windows shrunk to smallest visible, if dragged full size, draw the off-screen portions. Programs can be writing to the screen while resizing, the "VGA device" does the work.
The bottom line of each command line interpreter, I call the "hotspot", is always visible in a window; portions of the window larger than the box are virtually present, just not displayed.
The Z80 running MP/M or CP/M sees the screen as IO ports; one to write data to, one to specify the window. Magic keyboard keys (Fkeys) switch windows (MP/M: assigns keyboard to task window), arrow keys drag the "cursor" to resize all four at once, another key "maximizes" current screen (make largest; make 24x80; make tiny).
Lol, the cursor decided to not display for the video, there' still bugs to shake out etc.
You can resize the VGA display (480x640 to 1024x768) with program(s) running, and everything does exactly what you would expect. Can't do that with Xorg! Not that that's useful, lol, but the window buffering came out super clean.
This is event driven/task loop programming taken all the way; none of this is interrupt driven, it's all non-blocking task loops. Average task loop time (running through all dozen main tasks) is 5 - 10 uS, worst case 55 or so mS (large screen scrolling). I may unwind scrolling and drop that to a millisec or so but there's no downside I can determine.
MP/M will have four tasks, four "seats". on window per, and 48K per user/task, four running at once (and only four). MP/M performance will be very nice. Got the XIOS written, soon to test it...
Wee! I wrote a window manager for MP/M, four windows in the screen, dynamically resizeable, while program(s) are running.
Windows are virtually 24x80 "Heath H19" compatible, up to 30 x 90, so cursor ("curses") format windows shrunk to smallest visible, if dragged full size, draw the off-screen portions. Programs can be writing to the screen while resizing, the "VGA device" does the work.
The bottom line of each command line interpreter, I call the "hotspot", is always visible in a window; portions of the window larger than the box are virtually present, just not displayed.
The Z80 running MP/M or CP/M sees the screen as IO ports; one to write data to, one to specify the window. Magic keyboard keys (Fkeys) switch windows (MP/M: assigns keyboard to task window), arrow keys drag the "cursor" to resize all four at once, another key "maximizes" current screen (make largest; make 24x80; make tiny).
Lol, the cursor decided to not display for the video, there' still bugs to shake out etc.
You can resize the VGA display (480x640 to 1024x768) with program(s) running, and everything does exactly what you would expect. Can't do that with Xorg! Not that that's useful, lol, but the window buffering came out super clean.
This is event driven/task loop programming taken all the way; none of this is interrupt driven, it's all non-blocking task loops. Average task loop time (running through all dozen main tasks) is 5 - 10 uS, worst case 55 or so mS (large screen scrolling). I may unwind scrolling and drop that to a millisec or so but there's no downside I can determine.
MP/M will have four tasks, four "seats". on window per, and 48K per user/task, four running at once (and only four). MP/M performance will be very nice. Got the XIOS written, soon to test it...
I put together most of my retrocomputing bookshelf while learning Intel 8080 and CP/M programming, which reflects in the selection of titles. For more great photos of retrocomputing bookshelfs see:
https://retrocomputingforum.com/t/shelfies-bookshelves-with-a-retrocomputing-angle/190
Retro Computing Nostalgia meet Open Source Software and Hardware with AgonLight and Neo6502, the incredible evolution of modern Retro computer projects https://olimex.wordpress.com/2025/07/23/retro-computing-nostalgia-meet-open-source-software-and-hardware/ #z80 #w65c02 #retrocomputing #retrogaming #pascal #cpm #forth #basic #cc65
Retro Computing Nostalgia meet Open Source Software and Hardware with AgonLight and Neo6502, the incredible evolution of modern Retro computer projects https://olimex.wordpress.com/2025/07/23/retro-computing-nostalgia-meet-open-source-software-and-hardware/ #z80 #w65c02 #retrocomputing #retrogaming #pascal #cpm #forth #basic #cc65
Memoirs of the CP/M creator released:
“Our father, Gary Kildall, was one of the founders of the personal computer industry, but you probably don’t know his name. Those who have heard of him may recall the myth that he ‘missed’ the opportunity to become Bill Gates by going flying instead of meeting with IBM. Unfortunately, this tall tale paints Gary as a ‘could-have-been,’ ignores his deep contributions, and overshadows his role as an inventor of key technologies that define how computer platforms run today.
Gary viewed computers as learning tools rather than profit engines. His career choices reflect a different definition of success, where innovation means sharing ideas, letting passion drive your work and making source code available for others to build upon. His work ethic during the 1970s resembles that of the open-source community today."
https://computerhistory.org/blog/in-his-own-words-gary-kildall/
Memoirs of the CP/M creator released:
“Our father, Gary Kildall, was one of the founders of the personal computer industry, but you probably don’t know his name. Those who have heard of him may recall the myth that he ‘missed’ the opportunity to become Bill Gates by going flying instead of meeting with IBM. Unfortunately, this tall tale paints Gary as a ‘could-have-been,’ ignores his deep contributions, and overshadows his role as an inventor of key technologies that define how computer platforms run today.
Gary viewed computers as learning tools rather than profit engines. His career choices reflect a different definition of success, where innovation means sharing ideas, letting passion drive your work and making source code available for others to build upon. His work ethic during the 1970s resembles that of the open-source community today."
https://computerhistory.org/blog/in-his-own-words-gary-kildall/
Extremely decent ASCIIART benchmark result on @tomjennings 's Friendly eZ80 CP/M computer running BASIC-80 5.21 : 11.3 seconds
Another benchmark suggests that it's running BASIC 47× faster than a C64
A few weeks ago I wondered what it takes to turn a small LISP-1 into a LISP-2. Turns out it takes just a few hours to get most things right, then some days to iron out a few subtleties, and then a couple of weeks to polish it into a piece of art.
MICRO COMMON LISP is a tiny, purely symbolic, microscopic subset of #CommonLISP. It runs in less than 64K bytes of memory, even on #DOS (tiny model) or CP/M. Here it is:
http://t3x.org/mcl/
#CPM#LISP
The Mini #CommonLISP I have been working on now runs on CP/M with 2416 free cons cells. Enough to load Ken Kahn's tiny PROLOG and run a few simple queries.
The #AgonLight (18MHz eZ80) loads the LISP part of the code (236 lines) in 11 seconds. Simple programs run at acceptable speed, but slightly more complex PROLOG queries take minutes. 😊
#LISP#CPM#PROLOG#Z80
The Mini #CommonLISP I have been working on now runs on CP/M with 2416 free cons cells. Enough to load Ken Kahn's tiny PROLOG and run a few simple queries.
The #AgonLight (18MHz eZ80) loads the LISP part of the code (236 lines) in 11 seconds. Simple programs run at acceptable speed, but slightly more complex PROLOG queries take minutes. 😊
#LISP#CPM#PROLOG#Z80
A space for Bonfire maintainers and contributors to communicate