Re: colors in dos
- Posted by jimcbrown (admin) Jun 24, 2013
- 1854 views
@ Kat
IMHO: Modern PC's are built for end users (application users) who won't be tinkering with homebuilt hardware interfacing.
Good thing, because basically, they cannot, no matter how much they want to!
But, if you wish to play with hardware interfacing, I'm sure you have heard of the Arduino and clones.
For myself I play with PIC chips too, they are cheap and there are many models to choose from to get your mix of ports/memory/speed.
There is also the Raspberry pi which seems more software (mini Linux) based than hardware.
I built a small SPI board to plug into my AVR Dragon to program a slew of different AVRs, you need a programmer and a PC to use AVR or PIC. The AVR, PIC, Pi, Oak, etc do not come with the entire package of: keybd, programmable video output, programmable sound output, accessable cpu buss, several serial busses, programmable PIO ports, external storage interface, an OS, and an easily expandable programming language.
True, but stuff like the Arduino ($30) and Pi ($75) are a lot cheaper than, e.g., the Commodore 64 was ($575). I suspect that once a person buys the extra gear for the Pi (USB keyboard, USB harddisk, USB hub, USB floppy disk, speakers, SD card with Raspbian et al installed, etc), the total price is still below that of an Commodore 64.
Technically, you can add 2 gigabytes of ram to the C64,
Perhaps technically so, but due the (relatively) small bank size and the cost of bank switching, it's certainly impractical to make use of even 512 MB as RAM. (Though there are plently of other good uses, e.g. RAMdisk.)
(Minor irrelevant sidenote: I haven't been able to verify that specific amount (2GB) independently yet.)
you cannot do that with the Pi,
Correct.
or add memory-mapped anything to it,
Not true. For the interested, see http://elinux.org/RPi_Low-level_peripherals and http://electronics.stackexchange.com/questions/56205/use-raspberry-pi-gpio-header-as-memory-mapped-interface for examples on how to do it.
and the card doesn't have a programmable PIO port like a basic AVR does.
Well, the Pi at least has programmable PIO - see http://194.81.104.27/espen/CSY3015/Rpi_devices_and_the_PIO.html - though it may not be like the one a basic AVR has.
But the AVR has no video pins, the Arduino doesn't either. The Pi and the Arduino have no floppy or harddrive (the Pi has a slow-arse usb to share with with hdd?) support,
The Pi's USB harddisk support is reasonably fast. I can comfortably watch a multihour movie from it, for example. The Pi does support USB floppy disks as well: http://www.raspberrypi.org/phpBB3/viewtopic.php?t=10523&p=119980 thought admittedly, it comes with neither.
the C64 does. None of them have the SID chip. None of them can you add to the cpu buss, like adding a 2nd SID chip to make sterio, or 3 more SIDs to made quadraphonic sound.
It seems like it's possible in principle to add an SID chip to a Pi. http://www.raspberrypi.org/phpBB3/viewtopic.php?t=15307&p=156228
Or use an Arduino to emulate an SID chip: http://playground.arduino.cc/Main/SID-emulator
That's still a lot of work, but I suspect it's less effort than what would be required to get 2GB of RAM to work in a Commodore 64.
None come with an OS or programming language that "just works".
Correct.
Just look at the amount of code for a peek at the screen in the other thread about peeking at the screen!
For reference of other readers, that's http://openeuphoria.org/forum/121990.wc and http://openeuphoria.org/forum/121991.wc
In the C64, you simply literally peek at it. You can also move the "screen" around in ram, i did a lot of that, buffering screens, no "blitting", it took two pokes to tell the video chip that video memory was now somewhere else. Let me say it again: two pokes, not
Convert this code to Euphoria and adapt as required.
Such is the price of "monitor virtualization" (e.g. allowing multiple programs to access the screen at once). But, if a certain individual doesn't need monitor virtualization, then I agree that there should be a way to grant whole-screen access of this level to a single program, C64-style. Stupid M$.
Derek is, of course, correct. And he can do that level of stuff. My goal isn't to figure out what Microsoft is doing in the intricacies of the OS, and then how the hardware responds, i have an application i want to write. I have 600 page DOS manuals, if you cannot get the OS downto 600 pages, something is wrong.
I have 200 and 400 page Linux/GNU manuals. *shrug* But yeah, Windoze seems kinda - bloated.
Win95 came out at 6,250 times larger than the OS and the programming language total in the C64. And given how i expect Euphoria to act, i expect this should work:
object screen = gets(1) -- '1' is screen, as in puts(1,"hello") -- screen = {{screenline},{screenline},{screenline},etc}
Because, if you gets(AnyThingElse), you get lines segregated by agreed-upon separators (/n,/r,<enter>).
This is already supported as save_text_image().
EDIT: Actually, i use gets() to get a string, getw() to get a webpage, and getf() to get a file. It's well past time to have a getm() to get a monitor bitmap, because as Derek pointed out, the code already exists.
Bernie Ryan's eu_engin.e (which used SVGAlib, effectively granting the entire monitor to a single process) supported save_image(), which does this.
I think, for a windowed app (e.g. something using EuGTK and with many dialog boxes, and different forms exposed), there is room for this to get more complicated (do you want a screenshot-style entire monitor pixmap? just the active window? all the windows that belong to you? in the latter case, how do you want them organized? do you want the pixmaps of invisible/hidden windows as well?), and for that reason it's something that's best done in the widget library (EuGTK, wxEuphoria, EuIUP, w32lib, tinewg, etc) instead of in the stdlib.
