Previous Thread
Next Thread
Print Thread
Page 1 of 3 1 2 3
Joined: Jul 2009
Posts: 78
Ensjo Offline OP
Member
OP Offline
Member
Joined: Jul 2009
Posts: 78
Hello, all.

Before contributing to the MESS MC-1000 emulation, I worked with another MC-1000 emulation implemented as a Java applet. To it I added some clipboard operations that have been proving very useful: 1) Copying/pasting a (plain text) BASIC program from/to the RAM (where it is tokenized). 2) Copying/pasting blocks of bytes from/to the RAM (or VRAM). 3) Copying/pasting the content of the text screen.

The ability to "inject" program and data directly from the clipboard, without resort to "tape" files, is very helpful while you are developing a new program.

What do you think?

Joined: Aug 2009
Posts: 1,241
Likes: 152
Very Senior Member
Offline
Very Senior Member
Joined: Aug 2009
Posts: 1,241
Likes: 152
Isn't that already supported?

Joined: Aug 2004
Posts: 1,458
Likes: 9
Very Senior Member
Offline
Very Senior Member
Joined: Aug 2004
Posts: 1,458
Likes: 9
You can already paste as if you were typing it in. However it only works properly on some computers. Others produce gibberish.

Joined: Jan 2006
Posts: 3,691
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,691
Tafoid filed a bugzilla entry for the copy/paste problem with some systems (I think it depends on the delay some machines expect between sequential inputs)

concerning the original post, I think that he talks about something different. However:
1. copying and pasting RAM content requires some sort of snapshot format to be created, and however I think you can already use the debugger for that
2. BASIC tokens manipulation can be added to imgtool (I think coco supports this already if you need an example)
3. copying the screen content is something that I have no idea how could be implemented across the various different systems: one should probably intercept all the accesses to the RAM/VRAM and select the specific ones (it also reminds me too much the old hack used for c64 floppies, so that thinking to it already gives me nightmares... wink )

Joined: Jul 2009
Posts: 78
Ensjo Offline OP
Member
OP Offline
Member
Joined: Jul 2009
Posts: 78
Originally Posted by robbbert
You can already paste as if you were typing it in. However it only works properly on some computers. Others produce gibberish.
I know the pasting functionality that MESS has. It wasn't working well for MC-1000, then I recoded the keyboard input code and fixed it. Now it works almost properly, but the frequency of the pseudo-keystrokes is a bit too fast for pasting a long BASIC program, or one that has long lines, for instance. The time needed to process the input after every ENTER (tokenize the line and add it to the end of the program in RAM) causes the loss of the next keystroke (the first digit of the line number of the next line). I don't know if the frequency of these pseudo-keystrokes is adjustable in MESS.

Anyway, a long program still takes a lot of seconds to be inserted by this "pseudo-typed" pasting. The "injection" of data is immediate, and much more convenient. You can prepare a program in a text editor and paste it to the emulator every now and then for quick tests.

Originally Posted by etabeta78
concerning the original post, I think that he talks about something different.
Yes. smile

Originally Posted by etabeta78
However:
1. copying and pasting RAM content requires some sort of snapshot format to be created,
For BASIC programs, the format would be the program in text form. (Some escaping method could be considered to represent non-ASCII characters that many machines have.)

For generic RAM data, the format would be the same as in the Debugger's Memory Window: each line starts with an address, followed by a series of bytes to be inserted from that point on. (All hexadecimal, of course.) Example:
Code
3000 00 00 00 00 00 00 00 00 10 10 10 10 10 00 10 00
3010 28 28 28 00 00 00 00 00 28 28 7c 28 7c 28 28 00
3020 10 3c 50 38 14 78 10 00 60 64 08 10 20 4c 0c 00
3030 20 50 50 20 54 48 34 00
Some tagging convention could identify specific pieces/banks of RAM:
Code
[bank 1]
0000 00 00 00 00 00 00 00 00 10 10 10 10 10 00 10 00

[bank 2]
0000 00 40 40 48 43 20 30 33 34 4f 3b 20 20 20 20 20
Originally Posted by etabeta78
and however I think you can already use the debugger for that
Eh? I looked and found no copying or pasting feature in the debugger. Only direct typing.

Originally Posted by etabeta78
2. BASIC tokens manipulation can be added to imgtool (I think coco supports this already if you need an example)
Ugh, that stills involves creating a file (disk image?) in your system and loading it into the computer. And the machine emulated must have its disk capabilities implemented in MESS, which not all do.

Originally Posted by etabeta78
3. copying the screen content is something that I have no idea how could be implemented across the various different systems: one should probably intercept all the accesses to the RAM/VRAM and select the specific ones (it also reminds me too much the old hack used for c64 floppies, so that thinking to it already gives me nightmares... wink )
As it is the case with (de)tokenizing BASIC programs to/from the clipboard, that feature would need to be programmed independenty for each machine, with direct access to the (V)RAM.

Different machines have different BASIC dialects, with different tokens, stored in different formats at different points of memory. Internal pointers must be properly so that the machine knows the size of the program area.

As for the text screen, different machines have different screen sizes, different character sets, and so on... Some don't even have a "text" screen at all. In ZX Spectrum, for instance, characters shapes are stamped on a graphical screen, and the machine doesn't differentiate them from any line or dot plotted. It would be needed to compare every 8-byte-high screen square with the shapes in ROM to recognize the "text" content of the screen. For other machines, as those based on MC6847 like MC-1000 and the CoCo, it would be very trivial.

Joined: Jul 2009
Posts: 78
Ensjo Offline OP
Member
OP Offline
Member
Joined: Jul 2009
Posts: 78
It seems that my suggestion didn't rise much interest, at least here in the forums. frown

1. Is there a (more) proper channel to submit suggestions of change to the MESS core?

2. Is there any resource offered by the current core by which I could have read/write access the clipboard or a UI text box?

Joined: Mar 2001
Posts: 17,181
Likes: 211
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 17,181
Likes: 211
I would suggest you instead fix the existing paste functionality to support a longer delay at the end of each line first.

Direct RAM save/load is best done in MESS as a "snapshot" - look at other drivers implementing snapshots for guidance.

Scraping RAM or VRAM is a terribly ugly kludge and I would push for rejection of patches implementing it on any system in MESS.

Joined: Aug 2009
Posts: 1,241
Likes: 152
Very Senior Member
Offline
Very Senior Member
Joined: Aug 2009
Posts: 1,241
Likes: 152
Or adding a "common" keyboard sub-routine for MCU-based keyboards on which we don't have a dump for.

Joined: Jul 2007
Posts: 4,625
A
Very Senior Member
Offline
Very Senior Member
A
Joined: Jul 2007
Posts: 4,625
Quote
It seems that my suggestion didn't rise much interest, at least here in the forums.

I am interested, especially for exotic computers with rare or nonexistent software.
The only way is then to type for your self a language listing to run.

Joined: Jul 2009
Posts: 78
Ensjo Offline OP
Member
OP Offline
Member
Joined: Jul 2009
Posts: 78
Originally Posted by R. Belmont
I would suggest you instead fix the existing paste functionality to support a longer delay at the end of each line first.
I'm willing to do so, but... is it configurable on a per-driver base? How? (I'm still a newbie at programming for MESS, so more guidance is very welcome.) frown

Originally Posted by R. Belmont
Scraping RAM or VRAM is a terribly ugly kludge and I would push for rejection of patches implementing it on any system in MESS.
Forgive me, but why is that so? It's not obvious to me. As I said in the opening post, this feature is implemented in another MC-1000 emulator and it have been very, very useful. Editing a BASIC program in a text editor is much more comfortable that doing so in the machine, real or emulated, where I'm restricted to slow typing, one-line editing with slow cursor movement, no cut-and-paste, and so on.

(Don't take me bad. I am fond of the original machine, and programming in it is fun when you are in the mood to do so. But sometimes I just want to use a few minutes between my other occupations to try or improve a program for the machine to post on the wiki I set up for it, and doing that the usual way is just too time-comsuming.)

Even with a fully functional pasting feature, it is still "painful" to wait for long seconds (even minutes!) of beep-beep-beep-beep to get a full program in memory. And you don't have it the other way back: You can't (promptly) retrieve a program that you have typed in the machine after you edited it there.

Originally Posted by R. Belmont
Direct RAM save/load is best done in MESS as a "snapshot" - look at other drivers implementing snapshots for guidance.
Beyond the fact that a snapshot involves a file, it is originated in the machine. I get the status of the machine and save it so I can resume to that state later. People don't create snapshots outside of the machine. And (I suppose) it's generated in binary format, reflecting the RAM content, so the BASIC program is stored there in tokenized format, not text-only. Still, I can't (easily) use snapshots to insert an all-new program into the machine, and to retreive the source code of a BASIC program originally typed in the machine.

Given that, what is it that makes direct (V)RAM copying/pasting such an un-welcome feature?

Page 1 of 3 1 2 3

Link Copied to Clipboard
Who's Online Now
1 members (1 invisible), 41 guests, and 0 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,310
Posts121,714
Members5,070
Most Online1,283
Dec 21st, 2022
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com