276

(371 odpowiedzi, napisanych Fabryka - 8bit)

Hopefully FDISK can be made a little more intuitive through the use of dialog boxes:

http://atari8.co.uk/downloads/Dialog.png

Just an example, of course, although it's fully functional. Perhaps useful for disk geometry set-up, and preferable to a string of "Y/N" dialogs.

Someone also suggested an option to evenly split the available space into N partitions of equal size, with automatically assigned drive numbers. In addition, I need a mini MBR editor (or at least the potential to browse an MBR, possibly with extended partitions), so we can link up APT entries to FAT partitions and access them with the FAT driver.

277

(371 odpowiedzi, napisanych Fabryka - 8bit)

Nice font in the screenshots... other than that, someone please email me some questions in English. :)

278

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

Pin napisał/a:

Tzn - z tego powodu, że jest zbyt duży jak na CAR: to gryzie się z CON.SYS? ;)- Dziwne by to było, chyba że CON.SYS siedzi zaraz pod MemLo a FDISK ładuje się po prostu od jakiegoś adresu nadpisując akurat CON.SYS.

The 8KB FDISK is a relocatable SpartaDOS X application, so will overwrite nothing. Having said that, I tested it with S_VBXE.SYS (that's all FDISK needs to run in 80 column mode). Maybe CON.SYS leaves too little RAM free for FDISK's internal buffers? In any case I think there's a bug in the released version of FDISK, and Drac030 and I worked on fixing this a while ago. The next FDISK update will fix the CON problem, without a doubt.

Nie można mówić o "Two PBI ROMs may each have their own "master" IDE device," w chwili, gdy mamy SIDE2 bez Ultimete1MB. Wówczas SIDE nie jest urządzeniem NewDev... no chyba, że nie odrobiłem lekcji i się mylę? ;)

Simple example: IDE+ has IDE registers at $dxxx, SIDE has IDE registers at $dyyy... IDE+ will control its master device using its registers, and SIDE (be it via soft-driver or PBI ROM) will control its master device by a different set of registers. So, if you request LBA sector 0 of physical IDE device 1 (master) via the XDCB (32-bit physical sector address range), my estimation is that you'll get sector 0 from whichever driver gets hold of the DCB parameters first when SIO is handling the request. :)

279

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

Pin napisał/a:

FAT16.SYS?

gdzie to można znaleźć? ;)

Toolkit disk of SDX 4.46. :)

280

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

I aim to abandon the 8KB limited FDISK anyway: we'll get nowhere with that. If and when the 8KB size limit on CAR: is lifted, the larger FDISK can be placed there. :) FDISK is already absurdly complex under the hood because of the chain-linked APT.

If one question is how IDE+ and U1MB/SIDE co-exist (and I'm not sure it is: I'm reading through a thick curtain of translation here), FDISK doesn't care: it will be a case of whichever PBI driver intercepts an XDCB sector request first. Two PBI ROMs may each have their own "master" IDE device, and there's no provision in the APT spec for explicitly directing sector transfers to a particular PBI handler at the physical disk level. At the logical (partition) level, it could be different: you might have partition C: on SIDE and partition D: on IDE+: everything should be directed to the appropriate place then.

Anyway: not sure if that's relevant... but there it is. :)

281

(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.

282

(348 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.

283

(348 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.

284

(348 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.

285

(348 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?

286

(348 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! :)

287

(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. :)

288

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

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

289

(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.

290

(371 odpowiedzi, napisanych Fabryka - 8bit)

Competition? I know of none. :)

291

(371 odpowiedzi, napisanych Fabryka - 8bit)

lotharek napisał/a:

gotowe...prawie...

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

292

(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. :)

293

(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. ;)

294

(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.

295

(106 odpowiedzi, napisanych Fabryka - 8bit)

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

296

(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. ;)

297

(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.

298

(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/

299

(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

300

(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).