1. colors in dos

Hello everybody,

Is there a way to get more colors in dos besides those shown in graphics.e?

Like orange and gold?

I'm using the dos that comes with Windows 7

Don Cole

new topic     » topic index » view message » categorize

2. Re: colors in dos

DonCole said...

Hello everybody,

Is there a way to get more colors in dos besides those shown in graphics.e?

Like orange and gold?

I'm using the dos that comes with Windows 7

Don Cole

In the olden daze you could make a machine code routine to toggle between two colors, to get a color between them.

useless

new topic     » goto parent     » topic index » view message » categorize

3. Re: colors in dos

DonCole said...

Hello everybody,

Is there a way to get more colors in dos besides those shown in graphics.e?

Like orange and gold?

I'm using the dos that comes with Windows 7

Don Cole

See:
http://www.wagemakers.be/english/doc/vga
for changing to vga mode and 256 colors. Maybe. There's some assy code examples.
Also
http://www.osdever.net/FreeVGA/vga/vgatext.htm

useless

new topic     » goto parent     » topic index » view message » categorize

4. Re: colors in dos

DonCole said...

Hello everybody,

Is there a way to get more colors in dos besides those shown in graphics.e?

Like orange and gold?

I'm using the dos that comes with Windows 7

Don Cole

Versions of Euphoria that supported DOS let you do this via palette() or all_palette(), specifying the color in rgb format. This is relatively straightforward.

See http://openeuphoria.org/forum/m/31853.wc and http://www.rapideuphoria.com/lib_p_r.htm#palette and http://www.rapideuphoria.com/lib_a_b.htm#all_palette

However, IIRC you need to do so in graphical mode, which typically requires fullscreen mode. Considering the "dos" that you are using, it is possible that you may encounter issues in doing this. (E.g. http://www.tomshardware.com/forum/1441-63-full-screen-mode-programs ) If you get this problem, then an easy way to workaround it is to just run your program in dosbox instead.

new topic     » goto parent     » topic index » view message » categorize

5. Re: colors in dos

Thanks Kat and Jim,

I used to tinker machine language with my old Commodore 64.

It's been so long ago, that I forgot most of it.

So for what I'm doing i'm just going to live with the colors in graphics.e.

Thanks anyway.

Don Cole

new topic     » goto parent     » topic index » view message » categorize

6. Re: colors in dos

DonCole said...

Thanks Kat and Jim,

I used to tinker machine language with my old Commodore 64.

It's been so long ago, that I forgot most of it.

So for what I'm doing i'm just going to live with the colors in graphics.e.

Thanks anyway.

Don Cole

I tinkered on the C64 also, adding 32K of new machine code, adding resizeable wordwrapped windows and multitasking, in addition to mod'ing the existing two 8k roms. Not satisfied with that, i added a card to sync with incoming NTSC so i could test programmable sections of the NTSC signal from a video camera or vhs tape as shown onscreen, to do measuring and color detection. The C64 also interfaced to Modicon controllers to do data munging, display, and printout. The VIC20 made a very nice motor rpm/torque controller controller. The ZX80/ZX81 had a lot of promise, it's still disappointing that it failed. As you know, this was all before there was an IBM PC. There's nothing out there now (that i am aware of) which combines the ease of programming with the terrific hardware expandability of the computers of the early 1980's.

useless now,
wasn't useless back then.

new topic     » goto parent     » topic index » view message » categorize

7. Re: colors in dos

@ Kat
IMHO: Modern PC's are built for end users (application users) who won't be tinkering with homebuilt hardware interfacing.
Just doubleclick an app and thats all they want - you cannot blame the manufacturers for targeting the (guess) 98 % of the market!
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. Once you have the PIC chip programmer,
and I would advise an emulator too, there is lots you can do.
BTW, I too had the ZX81 (overheating problems due to small heatsink), the VIC20 (with 32K extra ram!) and the 64. I was proud of the 6502 assembly sort routine I did, but thats nothing to what you have done!

new topic     » goto parent     » topic index » view message » categorize

8. Re: colors in dos

fizzpopsoft said...

@ 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!

fizzpopsoft said...

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.

Technically, you can add 2 gigabytes of ram to the C64, you cannot do that with the Pi, or add memory-mapped anything to it, and the card doesn't have a programmable PIO port like a basic AVR does. 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 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. None come with an OS or programming language that "just works".

Just look at the amount of code for a peek at the screen in the other thread about peeking at the screen! 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

DerekParnell said...

Convert this code to Euphoria and adapt as required.

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. 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>).

useless,
and disappointed.

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.

new topic     » goto parent     » topic index » view message » categorize

9. Re: colors in dos

eukat said...
fizzpopsoft said...

@ 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!

fizzpopsoft said...

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.

eukat said...

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.)

eukat said...

you cannot do that with the Pi,

Correct.

eukat said...

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.

eukat said...

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.

eukat said...

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.

eukat said...

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.

eukat said...

None come with an OS or programming language that "just works".

Correct.

eukat said...

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

eukat said...

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

DerekParnell said...

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$.

eukat said...

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.

eukat said...

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().

eukat said...

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.

new topic     » goto parent     » topic index » view message » categorize

10. Re: colors in dos

jimcbrown said...
eukat said...
fizzpopsoft said...

@ 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!

fizzpopsoft said...

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.

The C64 was $575 the first year only, thereafter falling quickly to ~$200 for a while, and then falling again. Any other computer near the C64's abilities was $1000's more. Even as late as 1984, i could beat an IBM PC in functionality with a C64, and did take a job away from them.

You may question that, but i didn't rely entirely on the cpu speed or the buss speed. When an input needed counting, i used a set of 74LS163 in the rack, which was memory mapped and the program referred to those chips as a variable, which automagically zero'd the counter when read. IBM said they could not keep up with the rate of events happening, and could not rate the event counts and display in different colors. What little they could do was going to cost $50k and a year of time, i said $300 + parts and a month of programming. And remember, all they had was monochrome CGA.

jimcbrown said...
eukat said...

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.)

The ramdisk cart was a seriously bad way to make something work. The data in the ramdisk isn't used directly, it is slowly swapped with the internal ram data. The computer industry is hooked on buffering or repeated caching, seemingly putting in potholes to make it necessary. Even considering the 6502/6510 was the least expensive cpu back then, at 1Mhz the ram could have been accessed directly. Heck, i plugged two 5.25 racks full of cards into the main cpu buss slot, using only ribbon cable. So, for me, adding a 32bit counter to the ramdisk and using faster ram, and even dma, would not have been difficult.

<snip>

jimcbrown said...
eukat said...

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.

That url is 404.

<snip>

jimcbrown said...

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.

I disagree. Unless the programmer is using those other libs which extend Eu, Eu should default to using a basic "gets the window belonging to this app which has focus, or the whole monitor screen" with some option switch.

useless

new topic     » goto parent     » topic index » view message » categorize

11. Re: colors in dos

eukat said...

The C64 was $575 the first year only, thereafter falling quickly to ~$200 for a while, and then falling again. Any other computer near the C64's abilities was $1000's more. Even as late as 1984, i could beat an IBM PC in functionality with a C64, and did take a job away from them.

Well, I suppose you could argue that in unadjusted USD, a Pi + Arduno + full kit (usb keyboard, hdd, et al) costs more than $200. (I strongly expect that someone else will prove me wrong on this, however.) Still, how much is $200 USD worh in 1980s dollars?

From wikipedia: http://en.wikipedia.org/wiki/Commodore_64

Introductory price US$ 595 (today $1415.48)

According to http://inflationdata.com/Inflation/Inflation_Calculators/Inflation_Calculator.asp , $200 in 1985 is $432.98 today.

Once you adjust the dollars for inflation, the full kit is still cheaper than the C64 was.

eukat said...

You may question that, but i didn't rely entirely on the cpu speed or the buss speed. When an input needed counting, i used a set of 74LS163 in the rack, which was memory mapped and the program referred to those chips as a variable, which automagically zero'd the counter when read. IBM said they could not keep up with the rate of events happening, and could not rate the event counts and display in different colors. What little they could do was going to cost $50k and a year of time, i said $300 + parts and a month of programming. And remember, all they had was monochrome CGA.

I don't question this. From what I understand, IBM gave birth to the IBM-PC compatible market, and then destroyed itself there through it's own incompetence. Something like this is not surprising at all.

eukat said...

The ramdisk cart was a seriously bad way to make something work. The data in the ramdisk isn't used directly, it is slowly swapped with the internal ram data. The computer industry is hooked on buffering or repeated caching, seemingly putting in potholes to make it necessary. Even considering the 6502/6510 was the least expensive cpu back then, at 1Mhz the ram could have been accessed directly. Heck, i plugged two 5.25 racks full of cards into the main cpu buss slot, using only ribbon cable. So, for me, adding a 32bit counter to the ramdisk and using faster ram, and even dma, would not have been difficult.

The C64 had an 8bit cpu with a 14bit addressing space. I don't see how you could have avoided banking (which you call buffering/repeated caching).

Or perhaps I'm misunderstanding and you are just describing a better way to create a ramdisk than a ramdisk cart (a product that I am not familiar with). In the latter case, this sounds plausible and reasonable.

eukat said...
jimcbrown said...
eukat said...

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.

That url is 404.

How embarrassing for me. I feel like a first class fool.

http://webcache.googleusercontent.com/search?q=cache:77yo8lSXQ8wJ:http://194.81.104.27/espen/CSY3015/Rpi_devices_and_the_PIO.html%2Braspberry+pi+pio+port&hl=en&ct=clnk

eukat said...

I disagree. Unless the programmer is using those other libs which extend Eu, Eu should default to using a basic "gets the window belonging to this app which has focus, or the whole monitor screen" with some option switch.

Well, Euphoria doesn't support creating a window at all, aside from the basic console window (for which it has save_text_image). Thus, one must be using one of those other libs to create their window in the first place (or doing it by manually wrapping w32api calls, but someone able to do this would probably find coding the screenshot function to be a trivial task).

new topic     » goto parent     » topic index » view message » categorize

12. Re: colors in dos

jimcbrown said...

The C64 had an 8bit cpu with a 14bit addressing space. I don't see how you could have avoided banking (which you call buffering/repeated caching).

The 6502/6510 have a full 16 bits of address space. So does the 80286, and if you look at the 6510, the 6510 has a 6 bit port on the cpu which could have been used like the 80286's segment register, which if used well could have addressed 4 megabytes. However, 64K (even as 200ns dram) cost a cool $200 in 1981, which is why the ZX80/81 have 2k and the VIC20 has only slightly more. Anyhow, the C64 made huge use of the "zero page" for indexing, and a memory mapped selector (the same way i memory mapped 74LS163 counters) could have made 8k blocks of ram in the REU appear transparently in the internal ram space. Instead, they did time-costly data swapping i/o.

jimcbrown said...

Or perhaps I'm misunderstanding and you are just describing a better way to create a ramdisk than a ramdisk cart (a product that I am not familiar with). In the latter case, this sounds plausible and reasonable.

eukat said...
jimcbrown said...
eukat said...

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.

That url is 404.

How embarrassing for me. I feel like a first class fool.

http://webcache.googleusercontent.com/search?q=cache:77yo8lSXQ8wJ:http://194.81.104.27/espen/CSY3015/Rpi_devices_and_the_PIO.html%2Braspberry+pi+pio+port&hl=en&ct=clnk

Well, using a pio that way is certainly different than how the AVR and C64 do it: poke the DDR on the port you want to use, then read or write the port. And here i was saying there isn't any platform that is as easy and versatile to use as the C64. And how to do so was in the manuals supplied by Commodore. Ditto the analog joystick interfaces, the video chip (i made some custom chars in the char lookup table), etc etc.



useless

new topic     » goto parent     » topic index » view message » categorize

13. Re: colors in dos

eukat said...
jimcbrown said...

The C64 had an 8bit cpu with a 14bit addressing space. I don't see how you could have avoided banking (which you call buffering/repeated caching).

The 6502/6510 have a full 16 bits of address space. So does the 80286, and if you look at the 6510, the 6510 has a 6 bit port on the cpu which could have been used like the 80286's segment register, which if used well could have addressed 4 megabytes. However, 64K (even as 200ns dram) cost a cool $200 in 1981, which is why the ZX80/81 have 2k and the VIC20 has only slightly more. Anyhow, the C64 made huge use of the "zero page" for indexing, and a memory mapped selector (the same way i memory mapped 74LS163 counters) could have made 8k blocks of ram in the REU appear transparently in the internal ram space. Instead, they did time-costly data swapping i/o.

If I understand correctly, this is basically how banking works: http://sta.c64.org/cbm64mem.html http://codebase64.org/doku.php?id=base:memory_management

I don't see how one would make use of the 6bit port to extend the addressing space, but even if it was done, 4MB sounds like an awfully small size for a bank for 2GB.

In any case, I agree that this is a better approach than the time-costly data swapping i/o.

eukat said...

Well, using a pio that way is certainly different than how the AVR and C64 do it: poke the DDR on the port you want to use, then read or write the port.

Yeah, you read and write values to files instead. In a sense, this seems easier (and safer) than poking into memory addresses.

eukat said...

And here i was saying there isn't any platform that is as easy and versatile to use as the C64.

I think versatile is covered. As for easy ...

eukat said...

Ditto the analog joystick interfaces,

Yeah, seems like it's a bit more work on the Pi, though certainly doable:

http://www.newsdownload.co.uk/pages/RPiGpioPspAnalogJoystick.html

eukat said...

the video chip (i made some custom chars in the char lookup table), etc etc.

But the Pi can do HDMI outputs, 3D graphics, 24bit color, etc.

eukat said...

And how to do so was in the manuals supplied by Commodore.

Today, you have to get on the web for this kind of information.

OTOH, I have yet to see a manual that describes how to set up a Commodore 64 to use 2GB of RAM. I guess some kinds of versatile simply can't be covered in a manual.

new topic     » goto parent     » topic index » view message » categorize

14. Re: colors in dos

jimcbrown said...

But the Pi can do HDMI outputs, 3D graphics, 24bit color, etc.

HDMI didn't exist back then, and little else existed, including single chips for video displays. And memory for 24bit was too pricey then anyhow.

jimcbrown said...
eukat said...

And how to do so was in the manuals supplied by Commodore.

Today, you have to get on the web for this kind of information.

Imagine if Dell or IBM said "Here's a computer, YOU go find an OS for it, and how to use it!". Or "look at all the pins we put on this asic, YOU figure out what those pins do and what to connect them to!" Or "here's three choices of OS, none work properly, we'll give you user feedback on which works best later".

jimcbrown said...

OTOH, I have yet to see a manual that describes how to set up a Commodore 64 to use 2GB of RAM. I guess some kinds of versatile simply can't be covered in a manual.

jimcbrown said...

Today, you have to get on the web for this kind of information.


useless

new topic     » goto parent     » topic index » view message » categorize

15. Re: colors in dos

eukat said...

Imagine if Dell or IBM said "Here's a computer, YOU go find an OS for it, and how to use it!". Or "look at all the pins we put on this asic, YOU figure out what those pins do and what to connect them to!" Or "here's three choices of OS, none work properly, we'll give you user feedback on which works best later".

I imagine that if they sold it as a hobbyist option, and sold it for under $80, then they'd get as much demand as the Pi has now.

In relative terms, the MITS Altair 8800 did exceptionally well despite essentially being in the same condition - and originally, you had to solder the thing yourself to boot! http://www.pc-history.org/altair.htm

Not to mention, it was a lot more expensive than a Pi is today.

It is true that this hobbyist option would not appeal to the end users/application users - but something like a DIY Arduino must sound like a dream to the hobbyist who knows how to mess around directly with cpu pins and can create and attach racks of DRAM modules to it... and naturally Dell would continue selling the conventional option to its main market - a place where a C64 would not be able to sell (hey, how do I surf the web on this thing? how do I open up my M$ office document here? how do I check my email?).

eukat said...
jimcbrown said...

OTOH, I have yet to see a manual that describes how to set up a Commodore 64 to use 2GB of RAM. I guess some kinds of versatile simply can't be covered in a manual.

jimcbrown said...

Today, you have to get on the web for this kind of information.

Based on what I was able to find on the web, the maximum appears to be 1MB.

http://www.ktverkko.fi/msmakela/8bit/memory/index.en.html

http://www.zimmers.net/anonftp/pub/cbm/documents/projects/memory/c64/256kB/index.html


Forked into: [OT]Retro computing

new topic     » goto parent     » topic index » view message » categorize

16. Re: colors in dos

jimcbrown said...

Based on what I was able to find on the web, the maximum appears to be 1MB.

http://www.ktverkko.fi/msmakela/8bit/memory/index.en.html

That url is 404.

That one plainly says: "This directory contains the instructions for building an internal memory expansion of 256 kilobytes for the Commodore 64 computer." Whatever that was about, it wasn't ever about adding 2 gigabytes.

useless

new topic     » goto parent     » topic index » view message » categorize

17. Re: colors in dos

eukat said...
jimcbrown said...

Based on what I was able to find on the web, the maximum appears to be 1MB.

http://www.ktverkko.fi/msmakela/8bit/memory/index.en.html

That url is 404.

How embarrassing. Not again. :(

http://webcache.googleusercontent.com/search?q=cache:eTDsChx7SD4J:http://www.ktverkko.fi/msmakela/8bit/memory/memory-c64.pdf%2Bcommodore+64+adding+2g+ram&hl=en&ct=clnk

eukat said...

That one plainly says: "This directory contains the instructions for building an internal memory expansion of 256 kilobytes for the Commodore 64 computer." Whatever that was about, it wasn't ever about adding 2 gigabytes.

It was one of the few references that I could find that came close.

Other web pages claim that the C64 had an even smaller maximum amount of RAM, e.g. http://www.myoldcomputers.com/museum/comp/commodore_64.htm

It's hard to find any relevant links about this process on the web at all: http://www.google.com/search?hl=en&ie=UTF-8&q=how+to+add+2g+of+ram+to+a+commodore+64

I contend that, unlike the process of getting a Pi to work with an SID, it is not possible to find information on adding 2GB of ram to a C64 online from the web, as you implied:

eukat said...
jimcbrown said...

OTOH, I have yet to see a manual that describes how to set up a Commodore 64 to use 2GB of RAM. I guess some kinds of versatile simply can't be covered in a manual.

jimcbrown said...

Today, you have to get on the web for this kind of information.

new topic     » goto parent     » topic index » view message » categorize

18. Re: colors in dos

jimcbrown said...

I contend that, unlike the process of getting a Pi to work with an SID, it is not possible to find information on adding 2GB of ram to a C64 online from the web, as you implied:

eukat said...
jimcbrown said...

OTOH, I have yet to see a manual that describes how to set up a Commodore 64 to use 2GB of RAM. I guess some kinds of versatile simply can't be covered in a manual.

jimcbrown said...

Today, you have to get on the web for this kind of information.

Remember how i memory mapped 74LS163's on the external buss? What if i mapped four 74LVC574 (or some other latch) out there, and made a variable called EA (for external address), and i put the binary value of 2^30 into EA? Then on the other side of those 74LVC574 i attached 2GB of memory in whatever flavor i had handy, along with a few chips such that the last write into EA caused a rear or a write cycle (my choice) to occur on the ram? Lets say i had some space allocated in the memory map, and when i read or wrote there, it was picked off by the card holding my 2GB of ram, and used in that read or write cycle i mentioned? Gosh, that's just about how it can be done! And you know what else? I'll give you a freebie: the SID chip addresses are not fully decoded, you can decode those, use one block for those EA addresses, one for indexes, one for misc processing, one for transparent reads and one for writes, <!presto!> you have not taken out any ram inside the C64 to interface 2GB thru.

There, now that i have posted this, you can find it on the web.

useless

new topic     » goto parent     » topic index » view message » categorize

19. Re: colors in dos

eukat said...

There, now that i have posted this, you can find it on the web.

Yes, I agree. Now it is technically true that this information can be found on the web. I have no choice but to concede this point.

However, I feel that this is not up to the level of user-friendliness that a C64 manual has. E.g. http://www.commodore.ca/manuals/c64_users_guide/c64-users_guide.htm or http://www.commodore.ca/manuals/c64_programmers_reference/c64-programmers_reference.htm

Why? Simply put, I read one of those, and I have no questions on how things are done. When I read the your information, I have many more questions on how to do things.

Purely for reference purposes, I'll make note of some of my questions below. These questions don't need to be answered. (I'm not sure if I have enough time for the full back-and-forth required for the editorial process to make a mini-manual in any case.)

eukat said...

Remember how i memory mapped 74LS163's on the external buss?

I don't recall the exact technique used. How is this done?

eukat said...

What if i mapped four 74LVC574 (or some other latch) out there, and made a variable called EA (for external address),

How would you create EA?

eukat said...

and i put the binary value of 2^30 into EA?

This is possible, as gcc does something similar with its long long type on 32bit cpus. However, I don't know how to do something like that. How would you put 2^30 into EA?

eukat said...

Then on the other side of those 74LVC574 i attached 2GB of memory in whatever flavor i had handy, along with a few chips such that the last write into EA caused a rear or a write cycle (my choice) to occur on the ram?

How would you attach the memory to the 74LVC574s in a way to make them usable?

eukat said...

Lets say i had some space allocated in the memory map,

Where? And how much?

eukat said...

and when i read or wrote there, it was picked off by the card holding my 2GB of ram,

Wouldn't you be limited by the bank size to only 256kb at a time though? I'm guessing here (since you don't explicitly say so) that you'd use EA as a selector somehow to do this.

Would it be as simple as EA = 32bit memory address, then read/write one byte at a time?

eukat said...

and used in that read or write cycle i mentioned? Gosh, that's just about how it can be done! And you know what else? I'll give you a freebie: the SID chip addresses are not fully decoded, you can decode those, use one block for those EA addresses, one for indexes, one for misc processing, one for transparent reads and one for writes,

How do you fully decode those?

eukat said...

<!presto!> you have not taken out any ram inside the C64 to interface 2GB thru.

At the very least, some (tiny, perhaps a few bytes) of RAM is taken out for EA itself. Or have I misunderstood something?

new topic     » goto parent     » topic index » view message » categorize

20. Re: colors in dos

jimcbrown said...
eukat said...

There, now that i have posted this, you can find it on the web.

Yes, I agree. Now it is technically true that this information can be found on the web. I have no choice but to concede this point.

However, I feel that this is not up to the level of user-friendliness that a C64 manual has. E.g. http://www.commodore.ca/manuals/c64_users_guide/c64-users_guide.htm or http://www.commodore.ca/manuals/c64_programmers_reference/c64-programmers_reference.htm

Why? Simply put, I read one of those, and I have no questions on how things are done. When I read the your information, I have many more questions on how to do things.

I am not user-friendly any more. Threads like this are one of several reasons why. I am not going to teach you how to build or modify a microcomputer system.

jimcbrown said...

Purely for reference purposes, I'll make note of some of my questions below. These questions don't need to be answered. (I'm not sure if I have enough time for the full back-and-forth required for the editorial process to make a mini-manual in any case.)

eukat said...

Remember how i memory mapped 74LS163's on the external buss?

I don't recall the exact technique used. How is this done?

Read the datasheets on the parts, read the signals available on the C64 buss, figure it out, it's easier than baking a cake.

jimcbrown said...
eukat said...

What if i mapped four 74LVC574 (or some other latch) out there, and made a variable called EA (for external address),

How would you create EA?

You said you read the user-friendly manuals on programming that came with the C64, praps you should re-read them.

jimcbrown said...
eukat said...

and i put the binary value of 2^30 into EA?

This is possible, as gcc does something similar with its long long type on 32bit cpus. However, I don't know how to do something like that. How would you put 2^30 into EA?

It's called "programming", read the user-friendly manual on how to set a var equal to some value.

jimcbrown said...
eukat said...

Then on the other side of those 74LVC574 i attached 2GB of memory in whatever flavor i had handy, along with a few chips such that the last write into EA caused a rear or a write cycle (my choice) to occur on the ram?

How would you attach the memory to the 74LVC574s in a way to make them usable?

Properly.

jimcbrown said...
eukat said...

Lets say i had some space allocated in the memory map,

Where? And how much?

If i told you to take a breath, would you stop breathing until i told you where and how much?

jimcbrown said...
eukat said...

and when i read or wrote there, it was picked off by the card holding my 2GB of ram,

Wouldn't you be limited by the bank size to only 256kb at a time though? I'm guessing here (since you don't explicitly say so) that you'd use EA as a selector somehow to do this.

I do not know where you come up with that 256k number. How does it relate to 2^31, 64K, or 8bits?

jimcbrown said...

Would it be as simple as EA = 32bit memory address, then read/write one byte at a time?

eukat said...

and used in that read or write cycle i mentioned? Gosh, that's just about how it can be done! And you know what else? I'll give you a freebie: the SID chip addresses are not fully decoded, you can decode those, use one block for those EA addresses, one for indexes, one for misc processing, one for transparent reads and one for writes,

How do you fully decode those?

You'll find that information on the web, and in many datasheets.

jimcbrown said...
eukat said...

<!presto!> you have not taken out any ram inside the C64 to interface 2GB thru.

At the very least, some (tiny, perhaps a few bytes) of RAM is taken out for EA itself. Or have I misunderstood something?

Not if you do it like i said under "I'll give you a freebie:".

Are you going to drag this on, asking stupid questions, baiting and trolling me?

useless

new topic     » goto parent     » topic index » view message » categorize

21. Re: colors in dos

eukat said...
jimcbrown said...
eukat said...

There, now that i have posted this, you can find it on the web.

Yes, I agree. Now it is technically true that this information can be found on the web. I have no choice but to concede this point.

However, I feel that this is not up to the level of user-friendliness that a C64 manual has. E.g. http://www.commodore.ca/manuals/c64_users_guide/c64-users_guide.htm or http://www.commodore.ca/manuals/c64_programmers_reference/c64-programmers_reference.htm

Why? Simply put, I read one of those, and I have no questions on how things are done. When I read the your information, I have many more questions on how to do things.

I am not user-friendly any more. I am not going to teach you how to build or modify a microcomputer system.

Agreed.

eukat said...

I do not know where you come up with that 256k number. How does it relate to 2^31, 64K, or 8bits?

From one of the 404 websites - that one specified a total of 1M for the C64 by creating banks of 256KB each.

eukat said...

Are you going to drag this on,

Like I said,

jimcbrown said...

Purely for reference purposes, I'll make note of some of my questions below. These questions don't need to be answered.

I was simply trying to avoid criticism for not being specific enough about the differences.

eukat said...

asking stupid questions,

I think that these questions are reasonable ones, which plausibly could have come from a beginner.

eukat said...

baiting and trolling me?

mu

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu