HiassofT

phaeron, on Sun Feb 5, 2012 3:59 PM, said:

Thanks a lot for the info, I guess this should help quite a bit!

Now that you mentioned timeBeginPeriod() I also saw a reference to it in the docs of the Sleep() function - must have missed this back then :-)

Quote

At standard SIO speed this is no big problem, as each byte takes ages to transfer. But at higher speeds some SIO codes fail if there's no delay between complete and data. I found the following comment in my AtariSIO code:

/* QMEG OS 3 needs a delay of max. 150usec between complete and data */

I can't remember which other SIO implementations also need a delay, and how long it would need to be, I have the 150µs delay in my code for some time now, without any troubles.

so long,

Hias

JAC!, on Fri Jan 27, 2012 4:50 PM, said:

I wouldn't call it "many updates", actually it's just very few (minor) changes.

I worked with the latest release, version 0.6, as I wasn't too sure about the changes in trunk (and most people use 0.6, so this was a good basis to start, IMO). I've attached the diffs, splitted up in 2 files.

The first patch fixes problems with Pokey divisors 0 and 1 I was experiencing on my PAL 800XL. I set the baudrates to values actually supported by the FTDI chip to avoid possible rounding errors (resulting in too high speeds).

The second patch incorporates 3 changes:
- first a small backslash-escape issue in the project file and I also bumped the version number (so you can see in the About dialog that this is a patched version)
- then a (cosmetic) fix for the image size calculation in the "create image" dialog.
- plus add support for ATRs with 8192 byte sectors (both in the base "diskimage" code and also when creating new images).

ATRs with 8192 byte sectors isn't something people will need too often (putting a filesystem on top of it and using this on the Atari 8bits would be quite insane), but it was very handy for my flasher software, which accesses the flash cart in 8k blocks so one block could be read with a single SIO call (which is somewhat faster than 32 256-byte SIO transfers, especially on Windows machines).

I also tried to investigate why the performance (overall throughput) on Win32 was significantly lower than on Linux - on Win32 you have really huge delays between ACK and Complete (some 7ms) and between Complete and data frame (some 15ms). Especially at high transfer speed this was quite annoying. At divisor 0 a 256 byte data frame takes some 20ms to transfer, the delays add another 22ms so performance drops to almost 50% of what it should be.

It turned out this has to do with how the Win32 sleep function and scheduler work. There seems to be no easy way to get finer granularity than a standard Win32 timeslice in user-space. At least I haven't found a solution, but this doesn't mean too much as I'm no expert in Win32 systems. I tried to do busy-waiting using the performance counters instead of using Qthread::usleep(), but this didn't help much and also opens another can of worms on multiprocessor/core systems (where each core has it's own counters, and you need to take care of that). Maybe the multimedia timers (in single-shot mode) could help, but I haven't found the time yet to test this.

so long,

Hias

Marius1976, on Mon Jan 23, 2012 4:44 AM, said:

Yes, that's correct. We still have to re-calculate the final price (price of parts and PCBs tends to change slightly, and we also have to check shipping and packaging costs), so we haven't sent out payment instructions yet. And I also don't like to collect all your hard-earned money and then let you waiting for extended periods of time. As soon as we are ready to start production we'll contact you by email.

so long,

Hias

Update: I'm still swamped with work, haven't found the time to finish the docs, and Wolfram is moving to a new appartment (haven't heard from him in the past two weeks, so I guess he's still busy). So start of production is further delayed...

so long & thanks a lot for your patience,

Hias

Besides the minimum load issue (carefully check the datasheet, several lines like 5V or 12V might need a minimum load), there's another thing to keep in mind:

Those PC power supplies are usually able to provide 10-25A on the +5V and +12V rails. If you accidentally create a short circuit between +5V and GND on your Atari, there's a high risk of severe damage. Thin traces on the PCB or misplaced components might just vaporize...

I'd recommend using a wall-wart type PS rated at 2A-3A. This is more than enough power for the Atari, even if you have a lot of upgrades installed. I'm using 5V/2A wall-warts with most of my Ataris and retired my old AT power-supply (which also had a silent, but still audible, fan) some time ago.

If you also need the +12V (for a harddrive or a modded 1050), you can of course use a PC power supply - just don't forget to install fast blowing fuses in the power connections to your Atari and peripheral devices.

so long,

Hias