Mine are dripping at the thought if it. I've got the closest thing which is a jamma pc engine, but the game running on a modified taito board would beAlpha1 said:
Homebrew coding on arcade hardware
- Thread starter cmonkey
- Start date
ben76 said:
Still with the jealousy after all these years Ben tut tut tut
ben76 said:I prefer real computers not ones designed by the Early Learning CentreHurray Banana said:ben76 said:
Still with the jealousy after all these years Ben tut tut tut
- Ben
Ben you are being deliberately bad
Hah please no 8bit wars....I just tried to make a funny comment. Although it didn't have the library of the C64 (but still a VERY big one) almost every single arcade conversion is excellent. This may have been due to it's release date (1979) compared to others.
Anyway, indeed back on topic:
Yes I did plenty of Basic coding BITD. I even tried some tiny ML to move my Player/Missile graphics (= sprites, but Atari invented them) so fast I could barely see them on the screen compared to Basic.
One of the very first programs I wrote was one that simply defined a string in memory, opened the cassette port, read every byte from it into that string and of course write it back to tape as well. I never thought it would work, it was like a 10 liner or so but it did, and it made it possible to copy boot-tapes if you catch my drift. The most challenging part was finding the maximum size of that string that the system allowed while still running Basic. I found this by trial and error, simply using larger and then smaller and larger again strings in steps until I found it to the last byte. This was also the main limit of the program....you couldn't copy anything larger than that string.
Later I've written some Q-basic programs on PC for my dad's business. For some strange reason I never pursued a career in programming though...I am just never a master in one thing but have a wide interest in a lot of things
Level422015-07-06 19:15:31
Anyway, indeed back on topic:
Yes I did plenty of Basic coding BITD. I even tried some tiny ML to move my Player/Missile graphics (= sprites, but Atari invented them) so fast I could barely see them on the screen compared to Basic.
One of the very first programs I wrote was one that simply defined a string in memory, opened the cassette port, read every byte from it into that string and of course write it back to tape as well. I never thought it would work, it was like a 10 liner or so but it did, and it made it possible to copy boot-tapes if you catch my drift. The most challenging part was finding the maximum size of that string that the system allowed while still running Basic. I found this by trial and error, simply using larger and then smaller and larger again strings in steps until I found it to the last byte. This was also the main limit of the program....you couldn't copy anything larger than that string.
Later I've written some Q-basic programs on PC for my dad's business. For some strange reason I never pursued a career in programming though...I am just never a master in one thing but have a wide interest in a lot of things
Level422015-07-06 19:15:31
the biggest difficulty is trying to work with fixed tilemaps on arcade hardware compared to the bitmap frame buffer on the amstrad. Some data processing functional code can be studied and transferred over as Adrian demonstrated with the sound tracker on the taito l system.
Ben - are you referring to how difficult (or not) it would be to port CPC games to Spectrum or CPC games to arcade hardware?
The latter is probably slightly easier than the former.
And I didn't actually own a CPC until a couple of years ago, I was a Spectrum guy.
Hey Eric, did you know that Konami's Tutankham and Juno First are pure frame buffer based arcade boards without tiles? Juno First has a blitter to blit data from rom in the form of sprites but Tutankham doesn't even have that.
The latter is probably slightly easier than the former.
And I didn't actually own a CPC until a couple of years ago, I was a Spectrum guy.
Hey Eric, did you know that Konami's Tutankham and Juno First are pure frame buffer based arcade boards without tiles? Juno First has a blitter to blit data from rom in the form of sprites but Tutankham doesn't even have that.
no that's interesting as juno first chucks quite a bit around and it's z80
I assume the williams games have a similar setup (robotron defender etc...)
may have to take a look at those when I get the time.
may have to take a look at those when I get the time.
oops my mistake didn't read a Web page description beyond the words z80.
I meant as in the fact that the c64 wasn't z80 (obviously would be difficult on a z80 powered pcb) but as the CPC was z80 would it be a similar approach as to the Speccy?
Also I hope the CPC you got Ade is to prop a door open or something
Oh and to give the CPC a little bit of erm... credit if I must
.... as we know Ade after the Oliver twins talk they programmed the Dizzy games on a CPC and data transferred them over (or stuff to that effect!) So obviously there are compatibility comparisons between them game wise? So would it be a similar approach? Again I have no clue on programming, etc just wondering
- Ben
Also I hope the CPC you got Ade is to prop a door open or something
Oh and to give the CPC a little bit of erm... credit if I must
- Ben
I would think they programmed on an Amstrad for flexibility rather than any compatibilities. Nicer keyboard, screen, floppy discs, better assembler, etc rather than directly on the Spectrum.
I wrote an assembler on the CPC and used it to write code for the Jupiter Ace (which was horrible to type on).
I know Design Design used a Beeb to write their 6502 stuff because of its built in assembler. And I seem to remember reading Matthew Smith did Manic Miner on a TRS80...
I wrote an assembler on the CPC and used it to write code for the Jupiter Ace (which was horrible to type on).
I know Design Design used a Beeb to write their 6502 stuff because of its built in assembler. And I seem to remember reading Matthew Smith did Manic Miner on a TRS80...
I'm still not sure what you're on about dude!! Porting arcade games to CPC? Is that what you're on about?
I bought the CPC for a reason (related to Chuckie Egg 2) and since then it's been sat, unloved, in the spare bedroom. Suppose I should sell it really. I also bought a CPC6128 at the same time and it too sits, unloved, in the spare bedroom!
Games that were written first for Spectrum and then ported to CPC tended to be quick and dirty ports where the devs didn't expand the screen size (Spectrum screen is 256x192 pixels and CPC screen is 320x200 pixels in 4 colour mode) or make use of the better audio capabilities of the CPC. This left a lot of CPC users feeling a little bitter and angry (and rightly so I guess) as their machine wasn't getting the games that really pushed the machine.
Games that were written first for CPC and then ported to Spectrum needed much more rework due to the larger screen resolution and better audio of the CPC. I'm not aware of any games that were written first on CPC and then ported to Spectrum, but I'd imagine there are some.
I bought the CPC for a reason (related to Chuckie Egg 2) and since then it's been sat, unloved, in the spare bedroom. Suppose I should sell it really. I also bought a CPC6128 at the same time and it too sits, unloved, in the spare bedroom!
Games that were written first for Spectrum and then ported to CPC tended to be quick and dirty ports where the devs didn't expand the screen size (Spectrum screen is 256x192 pixels and CPC screen is 320x200 pixels in 4 colour mode) or make use of the better audio capabilities of the CPC. This left a lot of CPC users feeling a little bitter and angry (and rightly so I guess) as their machine wasn't getting the games that really pushed the machine.
Games that were written first for CPC and then ported to Spectrum needed much more rework due to the larger screen resolution and better audio of the CPC. I'm not aware of any games that were written first on CPC and then ported to Spectrum, but I'd imagine there are some.
The display technologies of the Spectrum and CPC were pretty similar in that they both had a frame buffer that could be addressed at the pixel level, so porting graphical stuff from Spectrum to CPC and CPC to Spectrum wasn't that hard. This approach to display technology was pretty low cost because all it needed was a few Kb of ram for the frame buffer and a low complexity IC (ULA in the Spectrum and CRTC in the CPC) to convert that frame buffer into a TV displayable image. This worked well for the CPC and Spectrum as they were low cost devices.
Arcade boards of the same era generally didn't have a pixel addressable frame buffer, instead they had much more powerful, dedicated (i.e. expensive) hardware in the form of tile map(s) generators and sprite generators. The Spectrum and CPC could happily do tiles and sprites (after all, that's pretty much what ALL games were comprised of back then, so they had to be able to do them!) but they had to be done in software, which consumed a huge chunk of the CPU's processing time per frame. Arcade boards, on the other hand, did all tile and sprite generation and movement using the expensive, powerful hardware, freeing up the CPU to do other things such as better AI for the bad guys, better collision detection, ability to have many more bad guys on screen at once, better frame rate, etc.
Take Gyruss for example, the 3D effect scrolling star field is actually comprised completely of lots of 1 pixel sized sprites in different colours. This same effect could be done on the Spectrum/CPC by simply moving lots of individual pixels but because Gyruss hardware can't access individual pixels it has to simulate this by using lots of 1 pixel sized sprites. This is not a problem for Gyruss as it has powerful sprite hardware (capable of drawing 48 sprites per frame) which can eat up such a task. However doing a similar thing on Pac-Man hardware wouldn't really be possible as it can only display 6 sprites at once. This is where having pixel level access to the frame buffer would be nice. Taito L System can display 120 sprites per frame so that makes it easier to simulate pixel level effects without being able to address individual pixels (which it can't do).
It would certainly be possible to port a CPC game to arcade hardware but, as Eric has mentioned above, to do so you need to change your way of thinking from software generated tiles/sprites and pixel effects to hardware generated tile/sprites and no pixel effects. There are some things which are more difficult to achieve when you don't have the ability to address individual pixels so you need to come up with a compromise where tiles and sprites can be made to behave in the same way. Not easy, but doable, usually.
Were there any games written exclusively for the CPC that would make a worthy port to arcade hardware, in your opinion?
Arcade boards of the same era generally didn't have a pixel addressable frame buffer, instead they had much more powerful, dedicated (i.e. expensive) hardware in the form of tile map(s) generators and sprite generators. The Spectrum and CPC could happily do tiles and sprites (after all, that's pretty much what ALL games were comprised of back then, so they had to be able to do them!) but they had to be done in software, which consumed a huge chunk of the CPU's processing time per frame. Arcade boards, on the other hand, did all tile and sprite generation and movement using the expensive, powerful hardware, freeing up the CPU to do other things such as better AI for the bad guys, better collision detection, ability to have many more bad guys on screen at once, better frame rate, etc.
Take Gyruss for example, the 3D effect scrolling star field is actually comprised completely of lots of 1 pixel sized sprites in different colours. This same effect could be done on the Spectrum/CPC by simply moving lots of individual pixels but because Gyruss hardware can't access individual pixels it has to simulate this by using lots of 1 pixel sized sprites. This is not a problem for Gyruss as it has powerful sprite hardware (capable of drawing 48 sprites per frame) which can eat up such a task. However doing a similar thing on Pac-Man hardware wouldn't really be possible as it can only display 6 sprites at once. This is where having pixel level access to the frame buffer would be nice. Taito L System can display 120 sprites per frame so that makes it easier to simulate pixel level effects without being able to address individual pixels (which it can't do).
It would certainly be possible to port a CPC game to arcade hardware but, as Eric has mentioned above, to do so you need to change your way of thinking from software generated tiles/sprites and pixel effects to hardware generated tile/sprites and no pixel effects. There are some things which are more difficult to achieve when you don't have the ability to address individual pixels so you need to come up with a compromise where tiles and sprites can be made to behave in the same way. Not easy, but doable, usually.
Were there any games written exclusively for the CPC that would make a worthy port to arcade hardware, in your opinion?