276

(15 odpowiedzi, napisanych Software, Gry - 8bit)

Right: low-down on FAT and APT, etc. If you want to have a FAT partition on the HDD which you can use with the FAT16.SYS driver, the partition entry in the APT partition table needs to point to the FAT partition as described in the MBR of the hard disk. This is the only way the partition will be visible to the PC AND to the Atari, since the Atari PBI / soft driver doesn't look in the MBR for partitions: it looks in the MBR for the APT entry, which is a pointer to the APT partition table. What's needed is a facility to LINK an APT partition entry to one of the MBR FAT partitions. I've done this with a hex editor before and it worked well, but I need to code something up in FDISK. It's not the easiest proposition, however, since I bascially need to add an MBR partition table browser to the software. You'd then select "Create external FAT partition", browse entries in the MBR, and press enter when you find the one you want. The Atari and PC would then both see this entry as - say - drive D:, and you could load the FAT driver on the A8 read files from it. If you put the FAT driver on CAR, you could even make it the boot partition. :)

Really, I'd like to add to FDISK the ability to create more than one FAT area on the disk, and this means a mini MBR partition table editor. So it's a question of finding the opportunity to get it done. I realize the FAT/APT size selection is about the weakest area of the software, and this is partly (though not entirely) because of the need to be concise in the 8KB CAR: version of FDISK.

The XEX loader does its own FAT housekeeping, and (in the final version) will simply "register" FAT partition information with the PBI driver. This relieves the PBI BIOS of having to parse MBRs and extended partition entries. The XEX loader will (when mounting an ATR, for example), simply pass the cluster number of the ATR to the PBI BIOS, along with the number of the registered FAT partition (which the XEX loader previously registered) the ATR resides in.

277

(345 odpowiedzi, napisanych Fabryka - 8bit)

drac030 napisał/a:

As for the scrolling speed, for starters I would suggest to compare not with the NC running on a 486, but with ICD's MENU - which, by the way, has only 10 lines to scroll, not 20.

No defense required: the main source of surprise was merely that S_VBXE doesn't fill a column noticeably faster than RC_GR8. I'd assume the software mode to be more CPU-intensive, but perhaps this is merely a testament to how staggeringly efficient the soft-driver is. :)

I choose not to impose arbitrary limits on directory length (256 files? Ok, why not 257?)...

Really - let's not feign ingenuousness: the value wasn't picked from a hat. 256 is the extent of 6502 indexed addressing.

...scrolling up/down the actual screen contents is not the only thing involved in the process.

If a complete directory isn't held in RAM, obviously portions of same are shuffled in when they come into view. But one would assume all twenty visible names are held in RAM while they're painted on the screen.

278

(345 odpowiedzi, napisanych Fabryka - 8bit)

Good point regarding PG UP/DN. The paged approach makes more sense in a multi-column display (such as TLW in 80 column mode), I suppose.

279

(345 odpowiedzi, napisanych Fabryka - 8bit)

As you wish. Personally I find at least being able to group files by TYPE when I need to, and name when I don't is indispensable. SORTDIR can't sort a directory two ways at once... ;)

Speaking of waste... of processor time, in this case: simplest way to overcome slow-scrolling problem is not to scroll the whole column by single lines, but to simply display the next "page" when the cursor is at the bottom. The cursor would then position itself at the top of the next list of 20 files - no repeated redraws needed. Do the reverse when the cursor goes past the top of the displayed list.

Just offering suggestions anyway... it looks really nice with the S_VBXE driver.

EDIT: oddest thing - scrolling seems no slower with the RC_GR8.SYS driver than with VBXE. I find this surprising.

280

(345 odpowiedzi, napisanych Fabryka - 8bit)

Why not limit files per directory to 256? My math: 23 (size of RAW entry) * 256 = 5,888 bytes. Sure - I can understand the desire to accomodate the theoretical upper limit of entries, but does anyone actually put more than 256 files in a directory?

281

(345 odpowiedzi, napisanych Fabryka - 8bit)

Won't get the chance to test this till later (it's Valentine's Day), but how many files per directory is SC catering for that it can't fit them in RAM in order to sort them? Folks with 1,000s of files per folder need to rethink their organisational skills! :)

282

(32 odpowiedzi, napisanych Sprzęt - 8bit)

Found it... adjustment is on two separate (neighbouring) components on this D2, but frankly it makes little difference to the colour averaging. Still - I've tweaked the pincushion and focus and the tube generally looks a little better. :)

283

(32 odpowiedzi, napisanych Sprzęt - 8bit)

Thanks Willy! I'd totally missed it, as it happens... I'll have another look.

284

(32 odpowiedzi, napisanych Sprzęt - 8bit)

Well, I can't find DL701 on the board... I wonder if it's a large grey square component in the very middle of the board, with a tiny screw in the top.

285

(371 odpowiedzi, napisanych Fabryka - 8bit)

Competition? I know of none. :)

286

(371 odpowiedzi, napisanych Fabryka - 8bit)

lotharek napisał/a:

gotowe...prawie...

Vastly improved on the original... can't wait. :)

287

(32 odpowiedzi, napisanych Sprzęt - 8bit)

Had the back off my D2 last night and poked around with an insulated screwdriver... could find no PAL delay line adjustment, although one pot eventually made the display black and white when adjusted. It had no effect on the colour averaging, though. The service manual for the P1 bears little relation to the D1/D2. Best solution is to move eyes further away from the screen. :)

288

(32 odpowiedzi, napisanych Sprzęt - 8bit)

I really think there's nothing wrong with your 65XE... again, these pictures resemble the output on my monitors. However, it would be nice to find a way to get rid of the defect, for sure.

I used to have one of those 1084ST monitors... it had a noisy tube, I recall, and a feint black line running down the screen. However, I wish I'd kept it, since it's a pretty rare model.

Of course these colour defects don't exist with LCD monitors: one of the few good things about LCDs. ;)

289

(32 odpowiedzi, napisanych Sprzęt - 8bit)

My 1084S-D1 looks exactly the same as this via Y/C. I believe it's because the Atari sends a non-interlaced signal, so half the lines are effectively empty... something like that. :) In any case, it's perfectly normal. RGB renders all the lines so you have no gaps - just nice solid colour.

290

(106 odpowiedzi, napisanych Fabryka - 8bit)

A video of me staring at the screen and prodding keys would be very boring, believe me. :D

291

(106 odpowiedzi, napisanych Fabryka - 8bit)

antek napisał/a:

Szkoda, że GUI umarł śmiercią naturalną... :-( bo ciekawie się zapowiadał :-(

From what did you derive this conclusion? I'm busy implementing completely new control structures, and designing the pre-emptively multi-tasking kernel. Unfortunately it's slow, time-consuming work. ;)

292

(15 odpowiedzi, napisanych Sprzęt - 16/32bit)

Is this M1721A supposed to be able to display ST hi-res via the DSUB 15? I can get a picture, but can't adjust the phase / clock enough to get rid of the black vertical bars. Shame, because this would have been a nice all-round monitor for all 3 ST modes.

293

(106 odpowiedzi, napisanych Fabryka - 8bit)

Demos for Amiga and ST mice (in port 2):

http://www.atari8.co.uk/downloads/guiAmi_011012.zip

http://www.atari8.co.uk/downloads/guiST_011012.zip

Functionality is limited, but you can close / open / full / restore / size / move windows and click desktop icons. File->Exit is functional, as are View->Icons and View->Text. There will certainly be a couple of small bugs, and problems with scroll bar positioning, etc, are known. Lack of RAM has prevented me from fixing these issues, and I'd rather move ahead to a cartridge build ASAP.

Load address is only $1200, so you'll probably have to boot the XEX. ;)

http://www.atari8.co.uk/gui/

294

(35 odpowiedzi, napisanych Sprzęt - 8bit)

macgyver napisał/a:

No właśnie takiego polecam - miał S-video i jakieś 8 lat temu kosztował ok. 300 zł.

I jakościowo nigdy nie narzekałem na jakość obrazu, zresztą można obejrzeć zdjęcia:

http://www.atari.apox.pl/art,58,monitor-vga.html

a urządzenie jest tutaj: http://www.samal.pl/katalogi/konwer/index.htm

Would this be the same converter?

http://www.ebay.co.uk/itm/190669852012? … 1423.l2649

295

(26 odpowiedzi, napisanych Programowanie - 8 bit)

nosty napisał/a:

Kurcze, tak z ciekawosci jak Wam to dziala? Bo na czym bym nie probowal to w trybie kolorowym dostaje wylacznie 85...

I've only tested it briefly with 1bpp images... seems to work fine (it'll save me a lot of time when converting bitmaps for use with the GUI).

296

(26 odpowiedzi, napisanych Programowanie - 8 bit)

gorgh napisał/a:

może to się przyda, Vega zmajstrował:

Superb: exactly what I was looking for! :)

297

(119 odpowiedzi, napisanych Fabryka - 8bit)

Great! BTW, did you get messages I sent you on AtariAge?

298

(180 odpowiedzi, napisanych Fabryka - 8bit)

Candle napisał/a:

all true ;)

and the fact i was ten minutes after your leaving on irc ;)

This is why they invented email. You can read them and respond to them any time - it's great. :)

I have sent email from an alternative address (see website).

299

(180 odpowiedzi, napisanych Fabryka - 8bit)

Much faster when my little parcel arrives and I can get response from Candle to numerous emails and attempts to locate on IRC, etc. :)

300

(106 odpowiedzi, napisanych Fabryka - 8bit)

Video of new window manager:

http://youtu.be/nKenrtfU-lM

After a long break, the project is back on track. :)