|  Post Your Message | |
| |
| | Previous Messages | Posted By
IstvanV
on 2007-12-10
09:25:51
|  Re: For Plus4emu
To Csabo: I do not know if this is suitable for your purposes, but in plus4emu 1.2.5, there is a simple scripting system now in the debugger.
|
|
|
|
Posted By
IstvanV
on 2007-11-30
09:19:17
| Re: For Plus4emu
Well, so far it seems that probably not 
|
|
Posted By
IstvanV
on 2007-11-27
17:53:13
| Re: For Plus4emu
More on scripting in the debugger: it is indeed possible to add support for running code written in a general purpose scripting language whenever a breakpoint is about to be triggered. The script could examine the CPU registers, memory, etc. and then decide if the debugger GUI should be shown like normal, or the emulation can continue without a break. Of course, it should also be possible to implement writing to memory, changing registers, loading PRG files, and maybe more. Would this feature be useful ?
|
|
Posted By
IstvanV
on 2007-09-20
15:29:32
| Re: For Plus4emu
The b($c0) type breakpoint that breaks when a particular memory address is accessed is already supported in all plus4emu versions. Although the debugger is not very well documented, so here is a quick list of what can be entered in the text editor widget at 'Watchpoints':
0c00 read or write $0c00
0c00rw read or write $0c00
0c00r read from $0c00
0c00w write to $0c00
0c00wp1 write to $0c00 if 'Priority threshold' is 1 or less (the default is 2 if no 'p' is used)
0c00-0fffw write to any address in the specified range
0004:e2 break at TED video position ($FF1C,$FF1D:$FF1E - line is the latched value and incremented
at column=$C2)
00cc:00-ff break at any cycle of line $00cc
c000-ffffi ignore other breakpoints if the program counter is in this range (no r,w,p modifiers are allowed)
The syntax elements can be combined, but video position breakpoints are only allowed for the main CPU and without read/write flags. You can enter any number of breakpoint definitions separated by spaces, tabs, or newlines.
If 'Ignore data reads' is checked, then only writes and opcode reads will be checked for breakpoints, and not data reads.
Setting 'Break on CPU jam' will cause the CPU jam instructions to be interpreted as NOPs with a 'p3' breakpoint set (note: $F2 is executed in more than 2 cycles, because it is used for special purposes). Otherwise, those instructions crash the emulated machine like the real one.
Creating some kind of scripting language would be useful eventually. It may also be possible to make the emulator engine usable as a library in high level languages like Python for full control over the emulation (of course, it is already possible to do that in C++); I do not know if users would actually find this usable in practice, though.
Unfortunately, I do not have a Palm, nor have experience developing for it, so I cannot port the code myself or write a new emulator from scratch (which may make more sense if the processing power is limited) for that platform.
|
|
Posted By
Csabo
on 2007-09-20
12:03:33
| Re: For Plus4emu
Here's my wish-list. I'd be happy to see these implemented in any emulator.
1) Palm OS support. I don't care if it's hard, I don't care that the Palm is dead, just do it... They ported Frodo to the Palm, it's open source: http://frodopalm.sourceforge.net/ I'm sure some of their code could help, or those developers might even join in.
2) A killer breakpoint system. I know some of these already exists.
Syntax: b <#bpnum> <expression>
If #bpnum is specified, then set the given breakpoint, otherwise set the next available one. If expression is empty, clear the breakpoint.
A simple expression evaluator is needed, where following things should be evaluated:
A,X,Y,S,PC (etc) should be special keywords, they should return the current value of A, X etc.
$00 any literal number
($1000) should return the value of memory location $1000
b ($0c00)<a should cause a breakpoint when the value of memory location $0c00 becomes less than the value in the accumulator, or
b pc<$400 & x!=$00 should cause a breakpoint when there's a jump to any address below $400 and X is nonzero.
Other special handles:
b ($c0) should cause a breakpoint when any opcode is accessing location $00c0. This would be super useful... I remember Luca posted something a while back when he didn't know what's overwriting his zeropage variables. Sometimes it's something like "STA $B0,Y" and Y=$10. There's no easy way to catch that currently. Perhaps This could be further broken down to: b ($c0) read or b ($c0) write - where those would cause breakpoints if the given address is read or written.
3) Expose all of the emulators functionality, and allow it to be controlled from user scripts.
I want to write a script like this and have an emulator execute it:
LOAD "sensible_hugo.prg"
B #1 $036C
TYPE "run<enter>"
STOP
#1:
SAVE "sensible_hugo.prg" (w:$2B) (w:$2D)
END
You get the point, right? With something like this, a lot of new and interesting things will become possible. For example, other programs will be able to use the emulator to remove packers (see above). Packers could be auto-detected and the script generated. Or, adventure (or other) games could be played "automatically", using brute force trial and error.
Those are my ideas.
|
|
Posted By
IstvanV
on 2007-09-18
13:56:04
| Re: For Plus4emu
There is some video recording code in the SVN now, here is an example file:
http://www.sharemation.com/IstvanV/test.avi.bz2
This feature is somewhat limited, though, since the video data is written without compression, so it takes up a lot of space, and a 2GB file is not much more than 8 minutes. Also, the chroma information is downsampled to half resolution, and the frame rate is 25 Hz (without these, the file size would be 4 times larger). Currently, the conversion to 25 Hz is done with filtering/interpolation, rather than just dropping frames, so there is some motion blur; I am not sure if the latter method would look better, although it would be definitely simpler and faster.
|
|
Posted By
IstvanV
on 2007-09-06
18:32:01
| Re: For Plus4emu
There is a new version (1.2.2) available for download now. The changes are:
* implemented Digi-Blaster emulation
* added limited support for error information in D64 files
* new option for setting SID model (6581 or 8580) to be emulated
* P00 format files can be loaded
* emulation speed percentage is now displayed on the title bar; it is also possible to set half, double, etc. speed in the menu
* the head position (track, side, and sector) of all floppy drives can be displayed in a window
|
|
Posted By
IstvanV
on 2007-09-04
16:23:31
| Re: For Plus4emu
To SVS: I have now added the speed percentage display, and it is also possible to set double, half, etc. speed. The drive head position display should be done soon, too. However, I am not sure if I can solve the symbolic keyboard mapping in the next version. Other than those, the remaining things to be done are digiblaster emulation, screenshots in PNG format (not sure yet), and maybe AVI recording.
|
|
Posted By
IstvanV
on 2007-09-04
06:23:37
| Re: For Plus4emu
The P00 support is very simple, though: when loading a program file, if it has an extension of .p00 (case insensitive) and begins with the string "C64File", then the first 26 bytes are skipped and the rest is loaded like a normal PRG file.
The exdos.rom, exos.rom, etc. are not for the Plus/4, and were used only by old emulator versions that supported multiple machines. These files are not included in new releases, but may have been left over from a previous installation; you can safely delete them. The latest set of ROM images is in http://www.sharemation.com/IstvanV/roms/plus4emu_roms.zip.
|
|
Posted By
Litwr
on 2007-09-04
04:16:50
| Re: For Plus4emu
Thank you very much!!! However what could you say about 'exdos.rom' , 'exos.rom', ... ? Please include information about all ROMs into plus4emu distribution documentation.
|
|
Posted By
IstvanV
on 2007-09-02
09:50:04
| Re: For Plus4emu
I have added read-only support for the P00 format.
|
|
Posted By
IstvanV
on 2007-09-01
09:20:49
| Re: For Plus4emu
Here is a list of ROM images that can be set in the emulator, with the corresponding file(s) in the ROM package:
Basic (low part of ROM bank 0, 16K)
p4_basic.rom
Kernal (high part of ROM bank 0, 16K)
p4kernal.rom (PAL kernal, revision 5)
p4_ntsc.rom (NTSC kernal, revision 5)
FuncL (low part of ROM bank 1, 16K)
3plus1lo.rom
FuncH (high part of ROM bank 1, 16K)
3plus1hi.rom
C1L (low part of ROM bank 2, 16K)
C1H (high part of ROM bank 2, 16K)
These can be used for external cartridges.
C2L (low part of ROM bank 3, 16K)
C2H (high part of ROM bank 3, 16K)
Second external cartridge; the p4fileio.rom file included with the emulator can be loaded to C2L.
p4fileio.rom allows loading/saving PRG files directly from/to the filesystem, and also includes a tape turbo
with four speed modes. It is controlled by the byte at $0647: the lower nibble is the device number to be used,
while the upper mode sets the mode:
$0x: filesystem access (you need to enable "virtual file I/O" in the machine configuration, and set the
working directory)
$1x: tape turbo, lowest speed (~2000 bits/second on average; zero bits are faster)
loading is still from the filesystem, since loading from tape does not need the ROM
$2x: tape turbo, average speed is ~2600 bits/second
$3x: tape turbo, average speed is ~3300 bits/second (uses half waves only)
$4x: tape turbo, average speed is ~4400 bits/second (uses half waves only)
The load/save vectors can be (re)installed with the monitor command G 063A.
1526 (1526/MPS-802 printer ROM, 8K)
1526_07c.rom (original firmware, revision 07c; this is the default)
1526_mod.rom (revision 07c German version modified by Erdmann Bloch for MPS-801 compatible graphics support)
1541 (1541 drive ROM, 16K)
dos1541.rom (original 1541 firmware, revision 5; this is the default)
dos15412.rom (1541-II firmware)
1551 (1551 drive ROM, 16K)
dos1551.rom
1581L (1581 drive ROM, low part, 16K)
dos1581.rom (revision 2, file offset = 0)
1581H (1581 drive ROM, high part, 16K)
dos1581.rom (file offset = 16384)
|
|
Posted By
Litwr
on 2007-09-01
02:21:23
| Re: For Plus4emu
:)
|
|
Posted By
Litwr
on 2007-09-01
02:19:39
| Re: For Plus4emu
It's difficult for me to understand usage of so many ROM-image files. Could you add so information about them?
|
|
Posted By
IstvanV
on 2007-08-30
11:36:49
| Re: For Plus4emu
I used TGA format (with 24 bits per pixel since there can be more than 256 possible colors due to the TV emulation, and 768x576 resolution for effects like interlace and increasing the dot clock with NTSC mode) for the screenshots because it was easy to implement without using external libraries. But PNG could be added with the use of libpng.
A more problematic issue will be video recording that I would like to add eventually: with no compression, 384x288/25fps/YV12 would take up 4 megabytes per second, while codec libraries like ffmpeg may have licensing issues.
I will have a look at the P00 format, and try adding support for loading it.
|
|
Posted By
Litwr
on 2007-08-30
05:58:13
| Re: For Plus4emu
The new release is great! However some things are matter for discussion.
* The screenshot files are big. Why do you use TGA format for the screenshots?
What do you think about PNG? BTW I got 115K TGA screenshot and converted
it to 7K PNG!
* There are some difficulties produced by absence of 'P00' format support.
It is so easy to add it for load program. Please...
|
|
Posted By
JamesC
on 2007-08-24
17:08:12
| Re: For Plus4emu
Regarding b) You could show the current track no. as well, so that user know that loading is on progress.
I think SVS is suggesting track and sector display, rather than the track twice.
I second this idea... it is handy when dealing with "defective" disk images, or we're just nosy as to what the program is doing with the disk drive. The Indus GT (1541 compatible) can do this, so this is not adding something just because another emulator does it -- it's because a track and sector display is a helpful tool.
|
|
Posted By
SVS
on 2007-08-24
06:06:28
 | Re: For Plus4emu
Regarding a)
yes I wish to see the shifted symbols like $, %, ? in order to let me to map them.
Regarding b)
You could show the current track no. as well, so that user know that loading is on progress.
Regarding c) and d) thank you for the suggestions that I'll try ASAP. Anyway the speed percentage is a good indicator to add
Bye and thanx once again.
|
|
Posted By
IstvanV
on 2007-08-23
13:21:54
| Re: For Plus4emu
a) I do not entirely understand this one. Do you mean some kind of symbolic keyboard mapping, or simply displaying the shifted symbols ?
b) Given that the disk emulation is true drive emulation, the progress of loading a file is not really known. However, it should be possible to display the current track number (there is already a similar feature in VICE) in some way.
c) Adding a speed percentage display is not difficult; in fact, I have thought about that earlier, just did not bother to actually implement it. If you cannot run the emulation in realtime on a fast machine, there might be video or sound driver related problems. Try these: reduce the "quality" setting in the display configuration, toggle single/double buffered mode, run in software mode (if everything else fails), or increase the "latency" parameter in the sound configuration.
d) I do not get stuttering sound (on Linux, Windows 2000, or running the Windows version under WINE on Linux), but one possible problem is that your sound card driver cannot handle the default sound playback settings. If that is the case, increasing the latency in the sound configuration could help (the optimal setting is the lowest with no stuttering). The "Hardware buffers" can also make a difference (click on the value display and drag the mouse left/right to change it); use the highest setting that works correctly. You may also try changing the sample rate or selecting a different device if the above fail.
|
|
Posted By
SVS
on 2007-08-23
08:38:41
| For Plus4emu
Since I guess IstvanV is back from his Summer holiday, I write a wishes list of new features to add on his good emulator (please IstvanV!):
a) On Keyboard config: Image shows only not-shifted letters/symbols. How to find the key for a symbol needing a SHIFT (the "?" for example). I suggest to flip image on keys-boxes when user hits SHIFT;
b) A progress bar when loading from disk would be an idea in order to not suspect a freeze crash in case of long loading (or even a loaded blocks counter);
c) A meter to know the emulation speed compared with real machine. I have an AMD 2800+ but I obtain only about a 60% of speed;
d) Emulated simple sounds (from BASIC command) are stuttered on my PC. This could be solved by assigning a better priority to emulator task against other running apps.
Many thanx
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
