ivop

April 5

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.

April 5

19 minutes ago, pps said:

The play routine in dmsc's routine doesn't initialize POKEY correct.

I have been bit by that bug, too, in the past

20 minutes ago, pps said:

STA SKCTL+16

Especially this one. That's why sid2gumby at first did not work on real hardware. Now it does

April 5

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

ProjectJenny-1.png.6679d2d0aed539190293d47cbdfbc84b.png ProjectJenny-2.png.61c154be88e1299ae4587b2ac6ce003c.png

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

April 5

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 )

April 5

9 minutes ago, danwinslow said:

I come from an Ada background

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.

April 5

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.

April 4

3 hours ago, Kaj de Vos said:

I was actually considering more to write my own C compiler on the same stack

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.

April 4

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.

April 3

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

April 2

19 minutes ago, ZuluGula said:

will have new SIO sockets, joystick ports, keyboard connector and power switches.

And card edge connectors. Soon

April 1

30 minutes ago, sanny said:

Hmm. You mean when compiling cc65?

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

April 1

20 minutes ago, drac030 said:

Might it be possible to just add a compile switch -DCRT0_OLD or so and get away with it?

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.

April 1

5 minutes ago, sanny said:

I see and in general agree with you. But changing this now changes behaviour as it was for the last 20 years. It's difficult. I don't want to piss off people because their program suddenly behaves different.

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.

5 minutes ago, sanny said:

I disagree. If there are command line arguments I want to have them in argc/argv and don't care how they ended up there,

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.

April 1

4 minutes ago, sanny said:

This is done to be cross-platform compatible. Ideally, compile a program for C64 and Atari, and the output is the same.

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.

April 1

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

April 1

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.

March 31

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

March 31

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.

March 31

20 minutes ago, CharlieChaplin said:

I have approx. 26 disk images with Colourview RGB pictures on them, none of them, really NONE of them has anything near 4096 colours, not even 256 colours.

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.

March 31

2 hours ago, ZuluGula said:

I have a few extra pieces of hardware. Is it a good time to sell, or I should keep it a little bit longer?

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

March 31

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

March 31

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