|  Post Your Message | |
| |
| | Previous Messages | Posted By
JamesC
on 2002-03-10
|  Well I wasn't "complaining"......
I was simply stating the fact that (until now) no Plus/4 emulator supported 1541 direct disk access.
I am happy to be proven wrong. 
I am also happy to report that YAPE 0.37 works just fine with Hitchhiker's Guide to the Galaxy, Zork 1, and Cutthroats. As you wrote, 1541 support must be turned on and 1551 support turned off, otherwise the loading program crashes (not an emulator crash but a failure in the Infocom software itself).
Now my next wishes:
1) an emulator that SAVEs to the .d64 directly. This would allow use of the file manager within the Plus/4 built-in software, among other things.
2) user-definable keyboard translation (use PC keyboard and the emulator software translates to equivalent CBM keyboard. If I press the SHIFT-2 I want a "@", and the emulator substitutes whatever the CBM keypress is to get the "@". If I press the SHIFT plus the button next to my Enter key on my PC keyboard, the emulator figures out that I want a " and substitutes a SHIFT-2. This feature would allow non-Commodore people like my wife to play with my emulator setup without my being here to tell her what key to press to get the desired effect.)
3) 1581 support via .d81, with a DOS wedge to allow simplified directory selection similar to PC DOS
4) support for USR and REL filetype within 1541/1551 emulation.
5) a unified way of determining what emulator is running my software, or if I'm running on a genuine Plus/4. This could be as simple as wedging a line or two into the hidden message SYS. I could SCNCLR, SYS to the hidden message, and then PEEK the last two lines listed to get an emulator name and author, or if I get the last two lines of the hidden message I know I'm running on the real machine. Or, put it in the USR function -- USR(+4) would not error out on an emulator, but instead give a copyright. Or it could be in DS$... as in:
? ds$(+4)
+4, YAPE 0.37, ATILLA (C)2002, GYROS@FREEMAIL.HU
READY.
A friend and I have some great ideas for Plus/4 software but we are limited by time and some of the limitations above. The Plus/4 is a great utility and programming machine, and should not be limited to game support when emulators are written/upgraded.
James C in NTSC-land
|
|
Posted By
Gaia
on 2002-03-10
| Nice list :)
Well, this is really a nice list, it'll make me motivated for some time more 
USR and REL support : these should work (as they are interpreted by the ROM of the 1541) but to be honest I haven't really tested it....
Regarding the 1581 format: what's this actually? I never knew it was possible to use an 1581 drive with the plus/4?!
If I find the time I'll also make an NTSC version
|
|
Posted By
JamesC
on 2002-03-11
| 1581 Support
The .d81 is 80 tracks of 40 sectors, with track 40 reserved for directory, leaving 3160 blocks available. It also supports partitioning like PC DOS. The 1581 reads an entire tack at once, so there is no interweave needed like on a 1541 or 1551. I can email more specs if you're interested.
The 1581 is a serial drive with turbo like the 1571, but uses 3 1/2" disks. I believe it is very similar to the drive in the Amiga line. The serial bus allows it to be used with any CBM serial computer from the VIC-20 through the 65 prototype. It is supported by Star Commander as of 0.82.13 beta (1998-02-22).
I have not had any problems running European emulators on my systems here in the States. When given the option, I change the frame rate from 50Hz to sync with the vertical blanking signal (WinEmu allows this) for those programs that don't run quite right on 50Hz.
James
|
|
Posted By
Gaia
on 2002-03-11
| Sounds interesting
Well, this is interesting Please send the docs away. Although, implementing the support could be a bit more complicated because I'd need some D81 files and probably a real drive wouldn't hurt either...
In the next Yape version, I'll add a feature to set the frame refresh interval between a certain interval (like 5 to 85 fps, below 50 it's basically a frame skip) in small steps.
Note: on WinEMU, the vertical blank synchronisation only means that the screen refresh rate (and the whole emulation) is not higher than that of your monitor, so it has nothing to do with PAL or NTSC. A difference from Yape is that it does not use up the spare power to speed up the CPU emulation (if that's possible). On Yape, it's now possible that the cpu emulation runs at 500% while your frames rate is limited to 85...
|
|
Posted By
JamesC
on 2002-03-12
| Refresh rates, etc
I will make a .d81 or two tomorrow evening; I need to get the children and myself to bed soon tonight. (It is 9:57pm CST here in mid-USA currently.)
I only adjust frame refresh when necessary because of screen flicker, for example when characters are used for animation.
When playing a game, adjusting the emulation speed may be beneficial, or may be detrimental ... depends on if my hand-to-eye coordination is good at that time.
From a programming standpoint, approximating the speed as closely as possible to the original 1.76 MHz border/.88 MHz screen display is desirable when displaying a screen while loading a file in the background.... the screen may not just be an opening graphic but instructions for use of keyboard, etc. Moving at 500% could possibly prevent the user from being able to read the entire screen, which is why I ask for the capability to determine if running under an emulator. If I know an emulator is being used I can add a "Press Spacebar to Continue" line or adjust my timing loop to compensate for users' not being able to read as quickly as the program is operating.
(Location 249 is flag for presence of 1551. Another idea for emulator is to store info in unused locations like 3048-3071 or 4072-4095, and flag presence in 1341.)
James C in NTSC-land
|
|
Posted By
Gaia
on 2002-03-12
| About emulator ID
Well, all that I can say is that it is not smart to put an emu ID into RAM at all Why? Simply, because it can be overwritten by any program any time. I hope I don't have to explain further the disadvantages of this
Further, the flags you mention are only standard for the built-in KERNAL ROM, and there's no guarantee whatsoever that other programs will care about that. For example: 1551 presence is simply determined by sending an ATN signal to the two IEC ports at and , if there's response, than the ROM writes a flag to the RAM area to remind itself next time that it is available. This check occurs like after every reset signals for example. It's similar to the behaviour of address , which stores the actually pressed key's code, but only for the KERNAL ROM. For other programs that might disable the ROMs (MANY, actually), this is useless (what more, they might want to use that space as free RAM) and you have to use the TED's keyboard latch at - and low-level...
Instead, it's more useful to patch the ROM. Namely, in case of the plus/4, there's a small empty ROM area between and for example. An emulator ID string could be simply written to there by user interaction, while the original content () could be restored by another click of a button
BTW: cheers for the 1581 drive specs. I am eager to get hold of a D81 file, too
|
|
Posted By
JamesC
on 2002-03-12
| Clarification of request :)
Atilla,
I think you missed my point about being able to identify whether I'm running under an emulator or not. I (or another author currently or in the future) would be writing programs to be used on a genuine Plus/4 or with an emulator, and may wish to adjust features of the program based on whether the program is on an emulator or on the real machine.
An example would be saving scores of a game. If I'm running on a real Plus/4 I would give option to save to tape or disk. On an emulator I would not give a tape option, but instead to instruct the user to select a .d64 to save to from the emulator functions, then press RETURN when ready to write to the .d64 (or not even attempt to save scores).
The idea is to be flexible with the use of the program, much like a boot program might detect between 16K or 64K system and load the appropriate version for the machine being used.
Commodore has used location 1 in the past but it is set differently for different emulators. I have not tried yours, but WinEmu and Minus4w both show 8, while Plus4 and the real machine show 200.
I noticed last weekend that one of the emulators has a bug. When selecting the machine type, setting to C232 automatically selects 3-Plus-1 ROMs. However, attempting to run 3-Plus-1 when in C232 mode crashes the C232 (not the emulator program). However I do not remember if it was YAPE or WinEmu that did this. I am at work at the moment (3:50pm here) and do not have my personal machines available to verify which emulator for you.
I will email two .d81s tonight. One will be the 1581 demo disk, the other a disk of my own compilation showing subdirectory structure, as the 1581 demo disk does not have a subdirectory on it!
James
|
|
Posted By
Gaia
on 2002-03-13
| It was clear :)
It was clear why you want this feature, but cheers anyway The biggest advantage in my opinion would be to detect the emulator to avoid using disk turbo loaders as they are not supported by the emulators...
Anyway, address 1 is again not a good idea That's the processor's I/O port for tape and serial disk access. Yape 0.37 now reports (200) at that address as the processor port is now sort of emulated correctly. This does not apply to Minus/4 and WinEMU though. But any well-behaving emulator will report this value similarly to a real machine. To clarify, here's a lowdown of that register:
I/O register of plus/4 at $01
7. bit IEC-data in
6. bit IEC-clk-in
5. bit - (out)
4. bit tape sense read
3. bit tape motor
2. bit IEC-atn-out
1. bit IEC-clk-out / tape sense write
0. bit IEC-data out
I know WinEMU once used the ROM address where the highest bit indicates the ROM version, ie. it's PAL or NTSC. For some reason, Zsolt seemed to disable this feature in recent releases... I put the question on the plus4 mailing list, hopefully the authors will react in due time.
Thanks for the files again, in advance.
|
|
Posted By
Gaia
on 2002-03-09
| Follow-up to the Infocom games
This message is mainly dedicated to Stefano and James C. A couple of posts ago you guys "complained" that Yape does not run these programs due to the inadequate drive emulation.
Well, yesterday I released a new version for Yape (0.37) that is with any luck should be able to load all Infocom games now. The advanced drive support is still preliminary, but at least worked on my side to a certain extent Note: you must switch OFF 1551 drive emulation (IEC), and turn on 1541 processor level emulation for proper working.
Cheers
Attila
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
