1. [OT]Retro computing
- Posted by jaygade Jun 24, 2013
- 2524 views
Forked from Re: colors in dos
Somewhat off-topic, 8-bit retro-computing is still pretty popular with hackers.
I've been enjoying reading about Quinn Dunki's build of a 6502-based computer with an ATmega-based video board: http://quinndunki.com/blondihacks/?p=680
Another project I've found interesting is the Uzebox (http://belogic.com/uzebox/index.asp) which is a retro game machine.
People also make various 68000-based machines and etc. You can find some good links at http://www.hackaday.com (along with lots of other interesting things).
We can do amazing things only DREAMED about when the C64 was new.
2. Re: [OT]Retro computing
- Posted by EUWX Jun 25, 2013
- 2443 views
Forked from Re: colors in dos
Somewhat off-topic, 8-bit retro-computing is still pretty popular with hackers.
I've been enjoying reading about Quinn Dunki's build of a 6502-based computer with an ATmega-based video board: http://quinndunki.com/blondihacks/?p=680
Another project I've found interesting is the Uzebox (http://belogic.com/uzebox/index.asp) which is a retro game machine.
People also make various 68000-based machines and etc. You can find some good links at http://www.hackaday.com (along with lots of other interesting things).
We can do amazing things only DREAMED about when the C64 was new.
On the contrary, I would look at very cheap super-hacking using FPGA
http://www.yosefk.com/blog/how-fpgas-work-and-why-youll-buy-one.html
3. Re: [OT]Retro computing
- Posted by useless_ Jun 25, 2013
- 2367 views
Is this where we talk about a 2014 version of the C64, running an OS written in Eu?
useless
4. Re: [OT]Retro computing
- Posted by jimcbrown (admin) Jun 25, 2013
- 2396 views
Is this where we talk about a 2014 version of the C64, running an OS written in Eu?
That works for me.
5. Re: [OT]Retro computing
- Posted by useless_ Jun 25, 2013
- 2371 views
Is this where we talk about a 2014 version of the C64, running an OS written in Eu?
That works for me.
I didn't mean talking about it with *you*. You spend all your time trying to disprove everything i say, instead of offering solutions. Jaygade began this thread.
useless
6. Re: [OT]Retro computing
- Posted by jimcbrown (admin) Jun 25, 2013
- 2410 views
Is this where we talk about a 2014 version of the C64, running an OS written in Eu?
That works for me.
I didn't mean talking about it with *you*. You spend all your time trying to disprove everything i say, instead of offering solutions. Jaygade began this thread.
I dispute that. You noted problems with getting a Pi to be able to have certain abilities (like using an SID), and I came up solutions from others for these problems at http://openeuphoria.org/forum/m/122006.wc
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.
As a start, may I suggest getting FreeDOS to run on a C64x http://en.wikipedia.org/wiki/Commodore_64x and then running VICE on FreeDOS?
Then we can start looking at replacing parts of VICE and/or FreeDOS with EuOS (the version by Matt Arriola).
7. Re: [OT]Retro computing
- Posted by jaygade Jun 25, 2013
- 2353 views
Is this where we talk about a 2014 version of the C64, running an OS written in Eu?
useless
Anything is possible, I guess. We were talking about "cool things to do with a C64" in the other thread, so I figured I'd fork it to a "cool things to do with 8-bit machines" and give some examples.
It's not necessarily Euphoria related, although it would be kinda neat to have a version of Euphoria which runs on more resource-constrained systems.
8. Re: [OT]Retro computing
- Posted by jimcbrown (admin) Jun 25, 2013
- 2361 views
It's not necessarily Euphoria related, although it would be kinda neat to have a version of Euphoria which runs on more resource-constrained systems.
Wasn't the original version of langwar such a beast?
9. Re: [OT]Retro computing
- Posted by jaygade Jun 25, 2013
- 2376 views
It's not necessarily Euphoria related, although it would be kinda neat to have a version of Euphoria which runs on more resource-constrained systems.
Wasn't the original version of langwar such a beast?
The original BASIC version of Trek would run on some machines like that -- it probably still required at least 8K of RAM I think. Maybe even 4K. I don't remember.
I remember reading the Euphoria was originally developed on an Atari ST which is the next higher generation from this class of machines.
10. Re: [OT]Retro computing
- Posted by jimcbrown (admin) Jun 25, 2013
- 2342 views
The original BASIC version of Trek would run on some machines like that -- it probably still required at least 8K of RAM I think. Maybe even 4K. I don't remember.
Do you know where that can be obtained from?
I remember reading the Euphoria was originally developed on an Atari ST which is the next higher generation from this class of machines.
I wish this was available as well. Heh, I wonder if it was originally written in BASIC!
11. Re: [OT]Retro computing
- Posted by jaygade Jun 25, 2013
- 2391 views
The original BASIC version of Trek would run on some machines like that -- it probably still required at least 8K of RAM I think. Maybe even 4K. I don't remember.
Do you know where that can be obtained from?
Google. http://www.atariarchives.org/bcc1/showpage.php?page=275 I've browsed Atari Archives before, lots of good 8-bit books. This particular link takes you to a Creative Computing article on Trek, with history and source code. Each page looks like it's both scanned in and converted to text (both on the same page).
I've downloaded a lot of these old books somewhere and thought to convert some of these classic BASIC games to Euphoria, but I've never gotten around to doing it.
I remember reading the Euphoria was originally developed on an Atari ST which is the next higher generation from this class of machines.
I wish this was available as well. Heh, I wonder if it was originally written in BASIC!
I don't think so! I think it was originally written in C and assembler before Rob Craig converted it to DOS.
http://en.wikipedia.org/wiki/Euphoria_(programming_language)#History
Looks like the Wikipedia footnotes are broken, but those messages are probably here somewhere.
12. Re: [OT]Retro computing
- Posted by K_D_R Jun 25, 2013
- 2329 views
I don't think so! I think it was originally written in C and assembler before Rob Craig converted it to DOS.
YEP - original ST version was C and assembler. Rob said he never actually released his original Atari ST version of euphoria. I asked him to post the ST code way back when I still had an ST, no joy.
I had a lot of fun programming in GFA basic on my Atari ST. I loved the GFA basic editor - it had routine folding!
13. Re: [OT]Retro computing
- Posted by jimcbrown (admin) Jun 25, 2013
- 2353 views
I don't think so! I think it was originally written in C and assembler before Rob Craig converted it to DOS.
YEP - original ST version was C and assembler. Rob said he never actually released his original Atari ST version of euphoria. I asked him to post the ST code way back when I still had an ST, no joy.
A shame. I guess the code no longer exists.
Does anyone know if the current Euphoria is a direct decendant of that codebase, or did Rob rewrite it from scratch for DOS?
I had a lot of fun programming in GFA basic on my Atari ST. I loved the GFA basic editor - it had routine folding!
What's routine folding?
14. Re: [OT]Retro computing
- Posted by jaygade Jun 25, 2013
- 2314 views
Another message from history: http://openeuphoria.org/forum/m/29917.wc
15. Re: [OT]Retro computing
- Posted by K_D_R Jun 25, 2013
- 2331 views
I had a lot of fun programming in GFA basic on my Atari ST. I loved the GFA basic editor - it had routine folding!
What's routine folding?
procedure Do_Something() yadao simply: procedure Do_something() yada yada end procedure -- the routine above folds to simply: procedure Do_something() -- I would love to see such a feature implemented in ed.ex -- Kate and Geany have code folding, but I think both implementations -- need to be "tuned" a bit for euphoria.
16. Re: [OT]Retro computing
- Posted by jaygade Jun 25, 2013
- 2333 views
I forgot to mention the OUYA, which my son pre-ordered and just received today.
Hmm. I wonder if I can port Euphoria to it (it's Android-based). 
17. Re: [OT]Retro computing
- Posted by ed_davis Jul 03, 2013
- 2093 views
The original BASIC version of Trek would run on some machines like that -- it probably still required at least 8K of RAM I think. Maybe even 4K. I don't remember.
Do you know where that can be obtained from?
There is a Tiny version of Star Trek at: http://www.dunnington.u-net.com/public/startrek/startrek.asc
For fun, I converted it to C, C#, Java and a couple more. I need to create a Euphoria version of the same one day. The converted versions don't have any goto's, so it should convert to Euphoria pretty easily. For reference, the C version is less than 800 lines of code, so it is indeed tiny.
18. Re: [OT]Retro computing
- Posted by useless_ Jul 03, 2013
- 2131 views
The original BASIC version of Trek would run on some machines like that -- it probably still required at least 8K of RAM I think. Maybe even 4K. I don't remember.
Do you know where that can be obtained from?
There is a Tiny version of Star Trek at: http://www.dunnington.u-net.com/public/startrek/startrek.asc
For fun, I converted it to C, C#, Java and a couple more. I need to create a Euphoria version of the same one day. The converted versions don't have any goto's, so it should convert to Euphoria pretty easily. For reference, the C version is less than 800 lines of code, so it is indeed tiny.
! ! Surprise ! ! Eu v4 has goto!
useless
19. Re: [OT]Retro computing
- Posted by K_D_R Jul 03, 2013
- 2068 views
The original BASIC version of Trek would run on some machines like that, it probably still required at least 8K of RAM I think. Maybe even 4K. I don't remember.
IIRC, a version of Trek ran on a basic VIC-20, which would have been 5k - screen memory = about 3.5k.
Even more astounding to me was the VIC's word processor, written in Basic 2.0 by TOTL software, which supported embedded footnotes. I think the first version of the Totl Text was pure basic, but subsequent versions had a printing routine written in machine language.
At one point, I toyed around with the idea of sponsoring a Euphoria programming contest to see who could come up with the best euphoria clone of Totl Text. Rob Craig talked me into sponsoring a contest based on some problems he had in mind. This was the very first Euphoria Programming contest.
I thought the first programming contest was a smash success. I learned something about "real" programmers - they love a challenge and they are highly competitive. I suspect that programmers who made over $50/hour nearly 15 years ago, gleefully spent hours perfecting code in order to win part of a $100 prize which was split between 1st, 2nd, and 3rd place winners.
Something else was accomplished by the first Euphoria Programming contest. At the time, in the mailing list discussions,there was a tremendous amount of acrimony and complaining about Euphoria's design and lack of features, etc. All of that stuff vanished, at least for the duration of the contest.
Pardon the digression.
Suffice it to say, a lot can be accomplished with 3.5k.
Regards, Ken Rhodes
20. Re: [OT]Retro computing
- Posted by useless_ Jul 03, 2013
- 2021 views
It was scarey that in the C64, only the first 2 letters of all the variable names mattered. So 'cow' and 'cog' were the same variable, and pairs like 'pr' referred to the function 'print'. I once wrote a routine to list all the letter pairs that were not broken up by reserved word pairs, and then alphabetical lists of all those pairs that were broken up. Using that list, and reserving ram for peeks and pokes of values in all the crannies of the memorymap, for one app i still ran out of names for variables. I didn't have much free memory either, i was using the ram under the roms for stuff as well. And a data dump to the printer full of fanfold at shift change could take 45 minutes.
I still have working VICs and C64s, and still would enjoy making a few improvements to them.
useless
21. Re: [OT]Retro computing
- Posted by fizzpopsoft Jul 03, 2013
- 2044 views
@ Kat
600 or so available combinations of variable names on the C64, and you ran out?
Obviously DIM didn't fit the need there. Just out of curiosity, what was the program spec?
My biggest Euphoria program is 8200 lines of commented source, with about 150 public or global vars.
That's hard enough for me to keep track of, the 600 odd must have been a nightmare -
your mental abilities to juggle those exceed mine!
22. Re: [OT]Retro computing
- Posted by useless_ Jul 03, 2013
- 2014 views
@ Kat
600 or so available combinations of variable names on the C64, and you ran out?
Obviously DIM didn't fit the need there. Just out of curiosity, what was the program spec?
My biggest Euphoria program is 8200 lines of commented source, with about 150 public or global vars.
That's hard enough for me to keep track of, the 600 odd must have been a nightmare -
your mental abilities to juggle those exceed mine!
Well, i was useful when allowed to be.
The C64 didn't have useful arrays that didn't use gobs of ram, there was something about DIM that was squirrely with math or garbage collection or ram use, or something, i forget. So i had to use "collections" of var names, like AA, AB, AC, AD, etc.. Most such arrays were broken before they got to AZ, or before i had a run like AA-BZ.
The app was to gather data from the real world, ~125 incoming lines, 5vdc or 120vac, simply counting most pulses so the time they came in wasn't critical, but did matter +/- a minute. The rate they came in could be several per second, and both incoming timing and when the C64 got around to them was asynchronous. All the vars were simply totalled for an hourly printout and a 8hr shift printout. However ~50 of them were also in a sliding timeframe that totalled within the immeadiate past hour, and then dropped out of the window as each entry aged over an hour (this really ate up the variables). Those in the sliding time frame were also tested for quantity to be colored on a screen based on qty in the window at the time. For instance, if 5 counts had been entered in the last hour, the line color was blue, if 20 were counted then the color was red. Each event on the ~50 lines had a timestamp good to a minute, and each event in the "collection" of vars was checked by timestamp against current time and forgotten if an hour old, and then each of the ~50 lines for the hour re-counted, re-colored, and re-displayed.
I tried to put the entire program in basic, but had to resort to putting some in machine code so i could cram it into any available ram and SYS to it as needed. If i could, i chose the code that ran most slowly to convert to machine code, if the resulting code would fit an available space. Vars handled infrequently also went into ram scattered around the machine, whereever it was available. Since the 10(?) bytes in zero page for the keybd buffer weren't used while the app ran, i used that too!
Part of the problem up front was that during paper printout the C64 would not respond to the incoming lines, yet counting still had to occur. So instead of anything else i could have used as input ttl chips, i used a couple of 74LS163's. This gave me a count of 255 at 30 million ticks/sec (3,700 million ticks/sec rate total across all 125 lines) before they'd wrap, and the machine being monitored would shut down before 100 ticks occurred on any one line, so i was ok with the lil 1Mhz 6510 being really slow with all those variables, and no ram left to perform garbage collection in.
useless
