ivop

When I did some recordings for the Lovebyte competition, I noticed there was a difference between calling Altirra.exe bla.xex from the command line, and loading an xex file from within the GUI. The amount of cycles burnt before your code starts running is not the same.

I have been bit by that bug, too, in the past Especially this one. That's why sid2gumby at first did not work on real hardware. Now it does

Decided to add mounting holes. This is gonna be (to me) an expensive 4 layer board, so it should be right at the first time Sacrificed two SIO slots, and moved the AN/Fast/Unbuffered bus a slot to the right. Still five slots. Only three will be used by the CPU, ANTIC and GTIA cards. With a proper buffered cable, this board can also be used as a CART/ECI hub or a SIO hub. That's all nice, but I also did something extremely stupid. I overwrote my only copy of the bus proposal .ods file with an empty sheet Now I only have the v9 pdf. Now I have to type it over again. Sigh but LOL at the same time. How can you be so dumb after all these years

Haha, I was about to edit my post, and add that Miranda was not that bad Another language I liked BITD was TCL (and TCL/TK, interactive GUI building )

Oh, I remember that. Had to do an assignment in Ada once. Wasn't that what NASA used BITD? Also did Smalltalk, Miranda, and some other long forgotten languages. The horror, the horror.

I checked my KiCad schematics, and they are correct in this regard. But, I could have made another mistake somewhere else I quadruple checked them with MyTek's original, and found no mistakes anymore the third and fourth time. And as MyTek says, no boards have ever been made. I probably never will. Instead, I'm cutting it up in pieces for Project Jenny, the Backplane Atari Computer project Edit: I'll use all MyTek's designs, plus the original Atari design, as a basis for that. One of the reasons for doing a backplane computer, besides that it's cool, is to eliminate having to order large expensive four layer boards over and over if one has made a mistake. If I make a mistake on a plugin card, I only have to re-order a card that is between 10x5cm and 20x10cm, and two layers.

I have considered doing that myself, too. Many times. There a a few pretty good C parsers, like tinycc, sparse, 8cc/chibicc, that are begging for a 6502 backend But then comes the question of how to implement that backend. Software stack ABI, we already have. So either like an embedded system, and use the hardware stack, or implement a VM that uses all extended memory as a continuous memory space, up to 1MB with Ultimate, and 4MB with an Antonia upgrade, and target that.

Why don't you target the 6502 directly? 1.5kB for Hello World is pretty big IMHO. In assembly or Action! or Basic, that's way smaller. I understand you want a C backend to quickly cover every platform that has a proper C compiler, but I doubt that's the right direction for 8-bit platforms if you want to compete with C itself, or Mad Pascal, or .... If you want your new language to gain any relevance, I would try an LLVM backend for current machines, and direct assembly output for oldskool 8-bit computers.

Progress. I started laying out the PCB. Decided 9 slots instead of 10 was better. There needs to be enough room for the overhang of socketed chips. Overhang will be on the side that is marked FRONT on the CART slots, for example if you plug in a SysCheck in the CART/ECI to supply RAM and ROM. This is just a prototype. It's 4 layers (ground and +5V power plane), and will be pretty sturdy if the PCB is 2mm thick. But later on I might have to sacrifice two SIO slots and one of the ANFU slots to make room for holes to screw this to a backplate/housing. And one or two screws somewhere in the middle of the board, to make inserting and especially removing cards less stressful to the PCB. I renamed this to Project Jenny, to my late mother who died way too young , and in the tradition of Atari to name projects after women

And card edge connectors. Soon

No, like drac030 says, it's a command line option when compiling something with CC65. Like how glibc has a gazillion ifdefs which are resolved at run time when the preprocessor runs through all the files. Current behaviour should be default, but a plain crt0.s without fiddling with the console would be nice if that got upstream. #ifndef __CRT0_NEW // current stuff #else // minimal setup for CC65 ABI #endif

Good idea, although I would do it the other way around. Keep standard behaviour of 20+ years the same, but add -DCRT0_NEW or something.

Yes, it's difficult. Changing expected behaviour is not something you want. And if all the CC65 targets do the same, probably leave it like that. Exporting the __LMARGIN symbol is probably the way to go, so a userspace program could set it back to what it was before calling the program. Agree. Should have been clearer. My remark was referring to Kaj's new compiler adding code to detect whether it was called from a command line DOS or not. That's not the job of a compiler.

I understand what you mean, but a cross-platform program in C just cannot rely on how the console "should" be. Imagine if every Linux command line utility would mess with my vt100/xterm settings. That's not acceptable. If your program needs shift lock pressed or unpressed, you need to do that in your program (like Pokey Explorer does). If you need printing to E: with a left margin of 0, you set that in your program (midimon does that). A compiler/library combination should not do that behind your back. And neither should a compiler add hidden code to detect whether you were called from a command line DOS or not. That's up to the program itself.

IIRC Lotharek's HUB runs most signals through Schmitt trigger buffers, which cleans up the edges of the signal.

IMHO crt0.s should only setup the required parameters to support the CC65 API ABI. It should not mess with console settings, like its left margin or shift lock status. Edit: I meant ABI, not API. API is the C standard.

Hmm, setting the margins, setting cursor inhibit, etc..., all take effect after a character is printed. That's the Atari OS behaviour.

Here's one from AtariMania, a Finnish add: No idea which year this was, but they did use Power Without the Price for an 800XL.

That sounds like either bad source material (probably 256 color GIFs), or a bad converter. BTW is this a flicker mode? I find flickering two screens barely bearable. Especially on PAL. Or does this mode keep a stable three lines "per line" display list? Then you just have to move your chair a couple of meters back to see the RGB illusion Edit: ran one of CharlieChaplin's ATR images. It's indeed a flicker mode. Let's say I'm not a big fan of flicker modes, or sometimes erroneously called interlaced. PAL blending, I like (without flicker). I believe visually the same hapens on NTSC if you just sit a bit back from the monitor.

Don't know, but don't wait too long. The potential buyers have to be still alive!

I just noticed they are even goldplated, although not shiny bright Today I updated the bus specification. I added +12V to the PIA/MMU/Misc bus, so the GTIA card would not have to source +12V from the SIO bus. +12V instead of a ~10V charge pump used for the color signal. I also laid out the bus on perfboards and adjusted the spacing/gaps between busses. Overhang is 150mil instead of 100mil. Adjusted for that. And increased the space between PIA/MMU/Misc bus and the CART bus. Even the widest carts should fit now. Now some design considerations. I was thinking about leaving even the power supply of the main PCB. Just a bus on top, some GND or Vcc fills, and a full GND plane. The power supply will be just another plug-in card. Would that be dumb? Also, I'm not sure yet if PIA and the MMU should live on one card, or on separate cards. Backplane Computer Bus v7.pdf

If I were you, I'd really move the vbi and dli to its own .s file, so you can get rid of all the asm("") stuff. dli pha rgb_cnt = *+1 lda rgb_table+2 ; be sure rgb_table is page aligned! sta wsync sta colbk dec rgb_cnt bpl __dli_done lda #2 sta rgb_cnt __dli_done pla rti Live coding in forum software So, it should work

To shorten your DLI, you invert the order of your table. Then it's just dey bpl __dli_done ldy #2 sty rgb_ctr

Nice punchy beat! Looking forward to your lead melody magic

Here's an .rmt I did not release yet AFAIK. It was a proof of concept of how to transcribe a song with siddump. It's one of my favorite SID songs. Original: https://deepsid.chordian.net/?file=/MUSICIANS/L/Laxity/Freeze.sid The extreme vibrato in the beginning was not possible with this Pokey setting. Anyway, I did this in Analmux's RMT 1.27patch6. And I transcribed the notes with siddump and entered them into RMT manually. Looking forward to your sound design laxity-freeze-rmt127p6-rc1.rmt