Tom
-
Posts
446 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by Tom
-
-
I never made a library. I can't remember in all details what I did years ago. Either I downloaded cc65 binaries or compiled my own. Then I read ist documents and figured out how to build startup code and a linker script. Lazy how I am I figured it wasn't necessary to build a special C standard library for the 7800. rfk7800 links to the c64 library and I simply paid attention not to use any function that actually does C64 specific stuff. That's usually the IO related functions. Also, I didn't set up a heap, so malloc/free won't work either. I don't consider this much of a problem. You just don't want to use a heap on something with as little RAM as the 7800.
If you have questions, ask them on the forum. There are People hanging around here who know a lot.
-
What build process? Do you want to build cc65 yourself or what?
-
I don't know, today I'm in the mood where words in quotes such as 'deadware' make me mad.
I'm pretty sure cc65 was the compiler 'GroovyBee was working on'. Ok, so Ullrich von Bassewitz has stopped maintaining it, but it's still available. That's all you need, as far as the toolchain is concerned.
The rfk7800 source is here: http://sourceforge.net/projects/rfk7800/files/rfk7800/. It can get you nicely started. It's using cc65 and gives you startup code and a linker script that produce Atari 7800 ROMs with cc65. I can't remember, but I can't believe GroovyBee didn't make his stuff available. And then there's the technical information made available by people such as Dan Boris, and the official programmer's manual has been available for quite some time as well.
As far as I know, that was the only C development library made for the 7800 - which saddens me immensely.Sorry, but that's just the usual whining. Documentation, tools and example sources are available, people just have to make use of them. Instead of crying.
Besides, I have no idea what you expect from a 'C development library made for the 7800'. Atari 7800 programming is all about putting together display lists and display list lists. This is all explained in the programmer's manual, which you simply have to read until you understand it. There's no way around this. And then your display management code is highly specific to your game and probably you'll end up writing it in assembly anyway.
-
1
-
-
devkitPro works fine on Windows 7, I've got it running here. You're just using it the wrong way. devkitPro should come with an msys environment. Use that instead of the plain Windows command prompt. Then use the GBA example sources and makefiles that come with devkitArm as a starting point. That should get you going.
You can get devkitArm working in a plain Windows command prompt, but this requires some digging in the devkitArm Makefiles and some gcc knowledge. For starters, devkitPro is designed so that multiple gcc versions can be installed in parallel and be all in the search path at the same time. To make this work they have their target platforms baked into their filenames. Your ARM gcc is called "arm-eabi-gcc", not just "gcc". Actually they might well be using a different prefix by now.
Also, I don't think you're setting all of the required search paths.
I've figured once out how to get devkitArm working in a plain Windows command prompt with gnuwin32 instead of msys (don't like msys very much), but I'd have to dig up some old source code to see what exactly I'd done.
If you just want to tinker with the GBA a bit and don't care much about your build environment, use the msys environment supplied with devkitPro.
-
ZIF socket, using 27C256s. I think it was a Digdug Cart I slaughtered. EPROM carts are very easy to build, and quite OK to work with. What annoys me most about this is that to burn the EPROMs I have to use a different PC since I can't get my EPROM burner to work with my new notebook.
I mean, at some point you rarely need to test on real hardware because you know more and more what you're doing. I do most testing on emulators, occasionally I burn an EPROM, and when I've used up enough of them to fill the eraser I'll erase them.
-
Well, I'm more waiting for easily available PCBs with EPROM, RAM and a socket for a sound chip (doesn't have to be a Pokey...you could stick in a CPLD or Micro emulating anything, right). That would be quite sufficient for me.
-
Also, the TIA's sound capabilities suck. While some people have done pretty decent music for the 2600 I don't think I'd want to do a 7800 demo with TIA sound. To be honest, the 7800 is a really ridiculous thing.
-
I don't know. I can only test 32k ROMs. I can't really think of anything much impressive, not without additional RAM.
-
Don't know, couple of hours over a couple of evenings. Music is taken from the 2600 version.
-
Actually I mean this. I enjoy some programming after work, but I don't have the energy to program games in my free time.
-
No. Too much effort.
-
1
-
-
scene.org, pouet.net etc. are down today, for whatever reason. In the meantime, grab it from the attachment.
Oh yes, fwiw, I coded this.
-
2
-
-
OK, the A3000 can be jumpered to be PAL or NTSC, so I quickly set it to NTSC and it works fine on my flatscreen, and it doesn't even look as bad as some people claim. At least to me the space savings and no 15khz beeping are worth far more.
The battery hasn't leaked yet, so whatever I do with the display I'll certainly try to replace the battery...any recommendations for replacement batteries?
-
If you original A3K battery is still there, it's also possible that battery damage has taken out the amber deinterlacer while your Amiga has sat around.
If that's the case, the Indivision ECS is the way to go.
Good point, will check the battery immediately when I get home today...apparently with the Indivision I have to remove or replace it anyway because it's too high. I've heard from people having trouble with A3000's that don't have a battery anymore. Does anybody have experiences with that?
-
Your Amiga 3000 outputs 60hrz VGA so it should work with just about any VGA CRT display.
It's a European model, wouldn't that be 50 Hz then?
-
I’m a bit confused.
So am I, apparently. I tried all VGA monitors I had, none of them displayed anything useful. One of them quickly displays a garbled workbench before deciding there's no signal. I'm pretty sure the A3000 is OK. It used to work with the 1935 monitor, although I don't have it around right now to test it.
-
Hi,
I've got an Amiga 3000 here, for which I'm looking for a monitor solution...I've got a 1935 Monitor which I originally got together with the A3000, but I hate it: it's huge, ugly and its ringing drives me mad.
What are my options to connect it to a modern VGA display? Should I get an Indivision ECS? Are they any good?
Cheers
Tom
-
Seems like the world is full of Jamie Zawinskis. I can't see any of them where I work, though.
-
...and there is more of a chance that hardware will work more like it's supposed to.
Even if you go and take the TIA circuit diagrams (which are floating around somewhere) and translate them 1:1 into, say, a VHDL description and synthesized that into a randomly chosen part I'd be totally unsurprised if the result sounded quite good but somehow different from an original TIA.
-
And why are you getting cocky now? Seems to me like the hardware forum is a technically oriented forum, and my question is technically oriented: what are your reasons to believe that a hardware implementation is necessarily superior to software emulation? Can you enlighten me on that?
-
And what makes you think a hardware clone is going to "act, look, and sound like a real Atari 2600"?
I say clone, but one of my hopes is that 'Atari' will finally allow someone to make a new updated version of the real Atari 2600 or Atari 7800. 'Atari' wouldn't have to do much of anything, just give permission. They might say that someone can make a real Atari, but it can't have the Atari name on it. No problem. As long as the guts work as expected, who cares about the name? (Just no cat names!
)Uh...it's not about names
The point is, you're putting too much expectation into hardware implementations over software implementations. In the case of sound for instance there are many things that may shape the final sound, including whatever particular chip technology they used to manufacture the TIA. Depending on how it's done (and what's possible, to some extent), you may end up disappointed because you get something that sounds quite but not entirely like the real thing. Hence my question: what makes you think a hardware clone just has to be better than software emulation?
-
And what makes you think a hardware clone is going to "act, look, and sound like a real Atari 2600"?
Especially the sound bit can be pretty hard to get right, and after all you are video modding your 2600s to get better pictures out of them than from "a real Atari 2600". Doesn't make sense to me. If you want the real thing, use the real thing. If you want an improved version you may aswell consider all possibilities, including software emulation which does have its merit.
Weren't you calling for a brainstorming?
-
Has it ever occurred to you guys that you can have most of those features you call for by putting an emulator onto an Eee Box or a similar PC that doesn't take up much space + depending on what you want some additional hardware (controllers etc.) + some minor configuration file hackery? This is exactly what I do...I have an Eee Box connected to my TV, Debian with freevo running on top. I don't use most of freevo's Music/TV/Movie features, I mostly use it as emulator launcher. Pause? Sure I can pause my games. If the emulator supports it, I can even save and restore states. It plays NES/SNES/whatever games. I can play Metal Slug on it. I operate the thing completely by Gamepad, except when I install additional stuff. Then I either hook an USB keyboard onto it or connect to it from my PC.
Sure a hardware clone has a certain coolness factor from a hacker's point of view. But for my own usage I prefer my Eee Box.
-
Hello,
I've got a Colecovision which behaves odd:
The AV-output delivers the video signal, but sound consists of noise only.
When the thing is powered on it often doesn't come up (video is noise aswell), hitting the reset switch (sometimes more than once) brings the system up. First I thought it's the cartridge connector, but the same thing happens also without a cartridge inserted (the "turn off before inserting cart" screen should show up then).
I know how to solder and the Coleco isn't exactly something I wouldn't touch, but I'm no good at finding faults in electronic circuits. Has anybody ever had a Coleco with similar problems and knows what it could be?
Cheers
Thomas
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Amiga: Blizzard 1230 Mk II or IV?
in Commodore Amiga
Posted
Hello,
I know there are more dedicated Amiga forums, but I keep forgetting my account details in these.
I've got an A1200 lying around which I've been wanting to upgrade for quite some time now. Now I've got the option to buy either a 1230 Mk II or Mk IV. The Mk IV is only slightly more expensive, so price doesn't really matter. The thing is, the Mk II is sold with 50 MB of RAM in total, while the Mk IV is sold with 8 MB of RAM only. So, which one would you go for?
Cheers
Tom