-
Content Count
8 -
Joined
-
Last visited
Content Type
Profiles
Member Map
Forums
Blogs
Gallery
Calendar
Store
Everything posted by MagerValp
-
Yes, but the Atari data is compressed in a custom format. One would have to disassemble the game to see how they're decompressed, presumably with some kind of LZ or Huffman scheme.
-
As Mermaid said the source is on GitHub and if anyone is seriously interested in remastering the Atari version I'd be happy to help. Most of the improvements should port straight over, but the main limitation is that the in-game graphics are limited to monochrome or artifact colors which I find a little underwhelming. The intro graphics could look pretty splendid though, but that really is the last part of porting - you'd have to bring up the main game, loader, compression, music, etc first. I'm curious if anyone could spread some light on how conversations are stored in the Atari version though. They're compressed, and I don't know enough about Atari disk structures to extract the data.
-
I'm sorry, I don't mean to belittle the improvements to Stella. Anyone that helps development should be supported, and adding post-processing is great. It's just that when I saw something about CRT simulation from a professor at a respected university, I expected more than run of the mill filters. Shouldn't the first steps be to analyze, understand, and document the phenomenon? I mean, take a look at Pepto's article on PAL colors, Blargg's information on sound emulation, or Antti Lankila's research into SID distortion. They did a ton of research and made emulators a lot more true to the original hardware. The filters look pretty neat, but Ian himself set the standard higher than that:
-
I read this a few days ago, and originally thought it sounded really interesting, but reading further I was disappointed. You appear to be reducing the complex interaction of the color encoding, the color carrier, the bandwidth limits, the electron beam hitting phosphors, and all the other details that make up an NTSC CRT based display system into "let's slap on some texture, delay, blur, and noise filters, and call it a day". It even appears to be done on RGB pixels, and not YUV and the frequency domain. It's also a bit scary to see that people seem to think of modern (i.e. TFT) displays as just "better". CRTs' main disadvantage were sharpness and size, but in nearly every other respect they were actually better: sporting wider color gamut, better contrast, resolution independence, no latency, and supporting a wide range of scan rates. While a modern TFT is better suited to the everyday tasks of users today, they're a major stumbling block when it comes to emulation.
-
[deleted]
-
cc65 and page zero abuse.. any workaround?
MagerValp replied to xt5's topic in Atari 8-Bit Computers
Hiya, this was discussed on the CC65 mailing list, and the solution is to use ++i in the for loop. i++ is an expression that returns a value, and then increments i, which is why the weird code is generated. With ++i the code becomes: ; ; for(i = 0; i < sizeof(data); ++i) { ; lda #$00 sta _i L0017: lda _i cmp #$D3 bcs L0018 ; ; data[i] -= 0x20; ; lda #<(_data) ldx #>(_data) clc adc _i bcc L0022 inx L0022: sta ptr1 stx ptr1+1 ldy #$00 lda (ptr1),y sec sbc #$20 sta (ptr1),y ; ; for(i = 0; i < sizeof(data); ++i) { ; inc _i jmp L0017 ; ; } ; L0018: rts You still get slightly convoluted code for the array code, as C uses ints for array indexing, which won't fit in the Y register. The compiler will never match the speed and size of handwritten 6502 assembler, so enjoy the faster development and better maintainability of the main code, and leave the speed critical parts in assembler (which is easy to call from C). -
Ultima IV: cracked copies/image concerns
MagerValp replied to Gunstar's topic in Atari 8-Bit Computers
Assembler. -
Ultima IV: cracked copies/image concerns
MagerValp replied to Gunstar's topic in Atari 8-Bit Computers
Hi! As I'm a bit of an U4 nut, Macbeth pointed me to this thread... On the C64 U3 uses $0400-$cdff, or 50.5 kB. However, eleven pages areas are untouched, bringing it down to 46.75 kB. The C64 also needs 1000 bytes of attribute ram for the bitmap. I haven't looked at the A8 port, but I don't think it would be too hard to fit music. If anyone wants to take a crack at it, I have a partial disassembly of the C64 music routine. Ultima V was released on C64 and Apple II, and Ultima VI was released on the C64. There are lots of Ultima remakes out there, and EA doesn't seem to mind too much. It's quite possible to release the remakes without the actual data files - users can copy them from the original. Ultima VI switched to an isometric view.
