James R Curry | 28 Aug 19:40

Random Sam BASIC question.

Okay, utterly random question...

How does one determine the start address of the screen in Sam BASIC?

I forget.

It has been years.

--
James R Curry
james-g2GopB7o33A@public.gmane.org
David Brant | 28 Aug 21:13
Favicon

Re: Random Sam BASIC question.

Normally the screen is at page 30 (or 14 on 256KB SAMs) so could write 'let sc=31*16384' extra page because of ROM0. Or you can use the following to get the current screen address. 
let sc=((peek 23160 band 31)+1)*16384
 
Dave
----- Original Message -----
Sent: Thursday, August 28, 2008 6:41 PM
Subject: Random Sam BASIC question.

Okay, utterly random question...

How does one determine the start address of the screen in Sam BASIC?

I forget.

It has been years.

--
James R Curry
james-g2GopB7o33A@public.gmane.org
Leszek Chmielewski | 28 Aug 21:22

Re: Random Sam BASIC question.

James R Curry schrieb:
> Okay, utterly random question...
>
> How does one determine the start address of the screen in Sam BASIC?
>
> I forget.
>
> It has been years.
>
> -- 
> James R Curry
> james@... <mailto:james@...>
SAM adv. technical manual says:

10 LET A=IN 252 BAND 31
20 LET BASE=(A+1)*16384

BASE=Start of Screen

greetings
LCD

P.S. But the structure of Information in Screen$ for Palette interrupt 
changes is unknown to me yet. |-D.

Thomas Harte | 28 Aug 21:37

Re: Random Sam BASIC question.

Port 252 is read/write? Anybody got any idea about ports 250 & 251?

On 28 Aug 2008, at 20:22, Leszek Chmielewski wrote:

> James R Curry schrieb:
>> Okay, utterly random question...
>>
>> How does one determine the start address of the screen in Sam BASIC?
>>
>> I forget.
>>
>> It has been years.
>>
>> --  
>> James R Curry
>> james@... <mailto:james@...>
> SAM adv. technical manual says:
>
> 10 LET A=IN 252 BAND 31
> 20 LET BASE=(A+1)*16384
>
> BASE=Start of Screen
>
> greetings
> LCD
>
> P.S. But the structure of Information in Screen$ for Palette  
> interrupt changes is unknown to me yet. |-D.

Leszek Chmielewski | 28 Aug 22:06

Re: Random Sam BASIC question.

251 = High Memory Page Register
250= Low Memory Page Register

Greetings,
LCD

Thomas Harte schrieb:
> Port 252 is read/write? Anybody got any idea about ports 250 & 251?
>
> On 28 Aug 2008, at 20:22, Leszek Chmielewski wrote:
>
>> James R Curry schrieb:
>>> Okay, utterly random question...
>>>
>>> How does one determine the start address of the screen in Sam BASIC?
>>>
>>> I forget.
>>>
>>> It has been years.
>>>
>>> -- James R Curry
>>> james@... <mailto:james@...>
>> SAM adv. technical manual says:
>>
>> 10 LET A=IN 252 BAND 31
>> 20 LET BASE=(A+1)*16384
>>
>> BASE=Start of Screen
>>
>> greetings
>> LCD
>>
>> P.S. But the structure of Information in Screen$ for Palette 
>> interrupt changes is unknown to me yet. |-D.
>
>

Thomas Harte | 28 Aug 22:09

Re: Random Sam BASIC question.

I meant are they read/write, or write only? However in the interim,  
I've found a copy of the Technical Manual online and discovered that  
they are read/write, which I wasn't expecting.

On 28 Aug 2008, at 21:06, Leszek Chmielewski wrote:

> 251 = High Memory Page Register
> 250= Low Memory Page Register
>
> Greetings,
> LCD
>
> Thomas Harte schrieb:
>> Port 252 is read/write? Anybody got any idea about ports 250 & 251?
>>
>> On 28 Aug 2008, at 20:22, Leszek Chmielewski wrote:
>>
>>> James R Curry schrieb:
>>>> Okay, utterly random question...
>>>>
>>>> How does one determine the start address of the screen in Sam  
>>>> BASIC?
>>>>
>>>> I forget.
>>>>
>>>> It has been years.
>>>>
>>>> -- James R Curry
>>>> james@... <mailto:james@...>
>>> SAM adv. technical manual says:
>>>
>>> 10 LET A=IN 252 BAND 31
>>> 20 LET BASE=(A+1)*16384
>>>
>>> BASE=Start of Screen
>>>
>>> greetings
>>> LCD
>>>
>>> P.S. But the structure of Information in Screen$ for Palette  
>>> interrupt changes is unknown to me yet. |-D.
>>
>>
>

Leszek Chmielewski | 28 Aug 22:23

Re: Random Sam BASIC question.

Sorry for the missunderstanding. Anyway, I'm sure that all memory paging 
ports are read and write ports, bacause there is no other way to 
determine which bank is currenly paged in.

LCD

Thomas Harte schrieb:
> I meant are they read/write, or write only? However in the interim, 
> I've found a copy of the Technical Manual online and discovered that 
> they are read/write, which I wasn't expecting.
>
> On 28 Aug 2008, at 21:06, Leszek Chmielewski wrote:
>
>> 251 = High Memory Page Register
>> 250= Low Memory Page Register
>>
>> Greetings,
>> LCD
>>
>> Thomas Harte schrieb:
>>> Port 252 is read/write? Anybody got any idea about ports 250 & 251?
>>>
>>> On 28 Aug 2008, at 20:22, Leszek Chmielewski wrote:
>>>
>>>> James R Curry schrieb:
>>>>> Okay, utterly random question...
>>>>>
>>>>> How does one determine the start address of the screen in Sam BASIC?
>>>>>
>>>>> I forget.
>>>>>
>>>>> It has been years.
>>>>>
>>>>> -- James R Curry
>>>>> james@... <mailto:james@...>
>>>> SAM adv. technical manual says:
>>>>
>>>> 10 LET A=IN 252 BAND 31
>>>> 20 LET BASE=(A+1)*16384
>>>>
>>>> BASE=Start of Screen
>>>>
>>>> greetings
>>>> LCD
>>>>
>>>> P.S. But the structure of Information in Screen$ for Palette 
>>>> interrupt changes is unknown to me yet. |-D.
>>>
>>>
>>
>
>

Thomas Harte | 28 Aug 22:57

Re: Random Sam BASIC question.

Oh, it was probably my fault for being unclear, since the original  
question was "how do I find out where the screen is" and the answer  
was "read port 252", then I guess that raises the presumption that  
other vague questions are about the function of ports, not whether  
they're write-only.

There are machines with write-only paging registers though. The Acorn  
Electron is definitely one. But it has a generally painful paging  
mechanism overall — per the documentation, to get to an arbitrary  
page, you have to request a page of one of the few ROMs that the  
keyboard and BASIC ROM can recognise to be not themselves so that  
they'll release the bus, then do your actual page; it took me ages to  
find a scheme for my Electron emulator that matched that documented  
behaviour and the expectations of all the software that just does  
whatever it feels like.

The OS ROM on that machine just keeps a record of the last thing it  
paged, and juggles as it feels correct when interrupts go. But it also  
steals about 3.5 kb of a 32 kb machine for various other things, so  
its help isn't always appreciated.

Anyway, blah blah blah, 250/251 being read/write makes some things I  
was mulling over much easier. I'm hoping to release my 3d wireframe  
code as a sort of engine for others to use. You just supply an  
'update' function and the code builds around it and calls it to do  
logic and drawing. There's a function call for drawing objects and  
that's about it. Obviously I'm going to need to be much more careful  
and open about paging.

I'm also giving serious consideration to knocking up a quick BASIC  
dialect to try to increase the code's reach to non-ASM people and make  
it more likely that some actual titles will be released. But if I  
manage that then it'll be through a PC/Mac-side compiler rather than  
any sort of Sam-based interactive environment.

Most importantly, I'm really, really keen to get what I have bundled  
up so that you don't have to understand it to be able to use it.

On 28 Aug 2008, at 21:23, Leszek Chmielewski wrote:

> Sorry for the missunderstanding. Anyway, I'm sure that all memory  
> paging ports are read and write ports, bacause there is no other way  
> to determine which bank is currenly paged in.
>
> LCD
>
> Thomas Harte schrieb:
>> I meant are they read/write, or write only? However in the interim,  
>> I've found a copy of the Technical Manual online and discovered  
>> that they are read/write, which I wasn't expecting.
>>
>> On 28 Aug 2008, at 21:06, Leszek Chmielewski wrote:
>>
>>> 251 = High Memory Page Register
>>> 250= Low Memory Page Register
>>>
>>> Greetings,
>>> LCD
>>>
>>> Thomas Harte schrieb:
>>>> Port 252 is read/write? Anybody got any idea about ports 250 & 251?
>>>>
>>>> On 28 Aug 2008, at 20:22, Leszek Chmielewski wrote:
>>>>
>>>>> James R Curry schrieb:
>>>>>> Okay, utterly random question...
>>>>>>
>>>>>> How does one determine the start address of the screen in Sam  
>>>>>> BASIC?
>>>>>>
>>>>>> I forget.
>>>>>>
>>>>>> It has been years.
>>>>>>
>>>>>> -- James R Curry
>>>>>> james@... <mailto:james@...>
>>>>> SAM adv. technical manual says:
>>>>>
>>>>> 10 LET A=IN 252 BAND 31
>>>>> 20 LET BASE=(A+1)*16384
>>>>>
>>>>> BASE=Start of Screen
>>>>>
>>>>> greetings
>>>>> LCD
>>>>>
>>>>> P.S. But the structure of Information in Screen$ for Palette  
>>>>> interrupt changes is unknown to me yet. |-D.
>>>>
>>>>
>>>
>>
>>
>

Leszek Chmielewski | 28 Aug 23:28

Re: Random Sam BASIC question.

Thomas Harte schrieb:
> Oh, it was probably my fault for being unclear, since the original 
> question was "how do I find out where the screen is" and the answer 
> was "read port 252", then I guess that raises the presumption that 
> other vague questions are about the function of ports, not whether 
> they're write-only.
>
Yes, but I should read next time more carefully |-D.
> There are machines with write-only paging registers though. The Acorn 
> Electron is definitely one. But it has a generally painful paging 
> mechanism overall — per the documentation, to get to an arbitrary 
> page, you have to request a page of one of the few ROMs that the 
> keyboard and BASIC ROM can recognise to be not themselves so that 
> they'll release the bus, then do your actual page; it took me ages to 
> find a scheme for my Electron emulator that matched that documented 
> behaviour and the expectations of all the software that just does 
> whatever it feels like.
>
To be honest, I houugh Acorn Electron has the same processor as C64 and 
Atari XL, and I was sure, they hawe no Ports and anything is 
memory-mapped (By the way, I currently extending my Retro-X to Acorn 
Electron and Amiga screen conversion, is your Electron Emulator probably 
for SAM???).
> The OS ROM on that machine just keeps a record of the last thing it 
> paged, and juggles as it feels correct when interrupts go. But it also 
> steals about 3.5 kb of a 32 kb machine for various other things, so 
> its help isn't always appreciated.
>
If you substract 10 to 20 Kb for the screen, there is not much left to 
code... Anyway, the games I have on Beeb suffer from this. Most games 
use monochrome hires or 4-Colour Fatpix mode.
> Anyway, blah blah blah, 250/251 being read/write makes some things I 
> was mulling over much easier. I'm hoping to release my 3d wireframe 
> code as a sort of engine for others to use. You just supply an 
> 'update' function and the code builds around it and calls it to do 
> logic and drawing. There's a function call for drawing objects and 
> that's about it. Obviously I'm going to need to be much more careful 
> and open about paging.
>
Releasing your 3D engine for others is a great idea, I saw the Videos on 
YouTube, I think, you can improve the speed of line drawing by optionaly 
draw every second pixel of the line on screen (like "Mercenary" on Speccy).
> I'm also giving serious consideration to knocking up a quick BASIC 
> dialect to try to increase the code's reach to non-ASM people and make 
> it more likely that some actual titles will be released. But if I 
> manage that then it'll be through a PC/Mac-side compiler rather than 
> any sort of Sam-based interactive environment.
>
Excellent idea (that is something I was planing for Retro-X, but as 
Cross-Suite, with supply for multiple Machines, with modern BASIC 
dialect and comfortable Scintilla-Based editor. Unfortunally I was never 
very good at coding in Z80 assembly, and using ROM Routines), I'm 
looking forward to see your work, as you are much more gifted coder than 
I'm.
> Most importantly, I'm really, really keen to get what I have bundled 
> up so that you don't have to understand it to be able to use it.
>
I understand  |-D.

LCD

> On 28 Aug 2008, at 21:23, Leszek Chmielewski wrote:
>
>> Sorry for the missunderstanding. Anyway, I'm sure that all memory 
>> paging ports are read and write ports, bacause there is no other way 
>> to determine which bank is currenly paged in.
>>
>> LCD
>>
>> Thomas Harte schrieb:
>>> I meant are they read/write, or write only? However in the interim, 
>>> I've found a copy of the Technical Manual online and discovered that 
>>> they are read/write, which I wasn't expecting.
>>>
>>> On 28 Aug 2008, at 21:06, Leszek Chmielewski wrote:
>>>
>>>> 251 = High Memory Page Register
>>>> 250= Low Memory Page Register
>>>>
>>>> Greetings,
>>>> LCD
>>>>
>>>> Thomas Harte schrieb:
>>>>> Port 252 is read/write? Anybody got any idea about ports 250 & 251?
>>>>>
>>>>> On 28 Aug 2008, at 20:22, Leszek Chmielewski wrote:
>>>>>
>>>>>> James R Curry schrieb:
>>>>>>> Okay, utterly random question...
>>>>>>>
>>>>>>> How does one determine the start address of the screen in Sam 
>>>>>>> BASIC?
>>>>>>>
>>>>>>> I forget.
>>>>>>>
>>>>>>> It has been years.
>>>>>>>
>>>>>>> -- James R Curry
>>>>>>> james@... <mailto:james@...>
>>>>>> SAM adv. technical manual says:
>>>>>>
>>>>>> 10 LET A=IN 252 BAND 31
>>>>>> 20 LET BASE=(A+1)*16384
>>>>>>
>>>>>> BASE=Start of Screen
>>>>>>
>>>>>> greetings
>>>>>> LCD
>>>>>>
>>>>>> P.S. But the structure of Information in Screen$ for Palette 
>>>>>> interrupt changes is unknown to me yet. |-D.
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

Thomas Harte | 29 Aug 01:26

Re: Random Sam BASIC question.

> To be honest, I houugh Acorn Electron has the same processor as C64  
> and Atari XL, and I was sure, they hawe no Ports and anything is  
> memory-mapped (By the way, I currently extending my Retro-X to Acorn  
> Electron and Amiga screen conversion, is your Electron Emulator  
> probably for SAM???).

Everything is memory mapped, but it's still registers at addresses,  
you just use the regular load/store instructions to write to them. The  
only difference of the z80 versus the 6502 is that it has a 17-bit  
address, adding a second 64kb can only be accessed by a IN/OUT.

My Electron emulator is for the PC/Mac, but I haven't released a new  
version in years. In any case, if you have any questions about  
anything on that front, feel free to drop me a line.

> Releasing your 3D engine for others is a great idea, I saw the  
> Videos on YouTube, I think, you can improve the speed of line  
> drawing by optionaly draw every second pixel of the line on screen  
> (like "Mercenary" on Speccy).

That would definitely help. There's quite a few more things I can do  
to speed it up without affecting the graphics first though. It's just  
finding the time. I think I'm relatively lucky because I don't work in  
anything to do with software so I don't end up with programming  
fatigue from my real life.

>> I'm also giving serious consideration to knocking up a quick BASIC  
>> dialect to try to increase the code's reach to non-ASM people and  
>> make it more likely that some actual titles will be released. But  
>> if I manage that then it'll be through a PC/Mac-side compiler  
>> rather than any sort of Sam-based interactive environment.
>>
> Excellent idea (that is something I was planing for Retro-X, but as  
> Cross-Suite, with supply for multiple Machines, with modern BASIC  
> dialect and comfortable Scintilla-Based editor. Unfortunally I was  
> never very good at coding in Z80 assembly, and using ROM Routines),  
> I'm looking forward to see your work, as you are much more gifted  
> coder than I'm.

Oh, this stuff is all much easier now than it must have been in the  
80s. And it's not just the wide array of information that is  
accessible through the internet, when I was learning 3d I found out  
that Elite achieves its near-solid look just by using convex objects  
by directly asking David Braben. Let's not pretend you would have been  
able to get that sort of help when that sort of information actually  
had commercial value.

Leszek Chmielewski | 29 Aug 13:11

Re: Random Sam BASIC question.

Thomas Harte schrieb:
>> To be honest, I houugh Acorn Electron has the same processor as C64 
>> and Atari XL, and I was sure, they hawe no Ports and anything is 
>> memory-mapped (By the way, I currently extending my Retro-X to Acorn 
>> Electron and Amiga screen conversion, is your Electron Emulator 
>> probably for SAM???).
>
>
> Everything is memory mapped, but it's still registers at addresses, 
> you just use the regular load/store instructions to write to them. The 
> only difference of the z80 versus the 6502 is that it has a 17-bit 
> address, adding a second 64kb can only be accessed by a IN/OUT.
>
> My Electron emulator is for the PC/Mac, but I haven't released a new 
> version in years. In any case, if you have any questions about 
> anything on that front, feel free to drop me a line.
>
Aha. I never stop learning. That was completly new for me...
For Acorn emulation I currently use Beeb. Just requested from the 
authors to have a binary PC file import and export-function for one of 
the next versions, like Sim Coupé. I have never heard about your 
emulator. Is there a Acorn Electron screen interpreter/viewer available? 
I should test the export of my screen converter, how it works on a 
emulator, but without binary import it is a bit hard.
Just noticed that my Amiga HAM6 IFF export looks fine on real Amiga 500, 
but some pixels are wrong if I view it with XnView on my PC (I guess, 
the line start colour was not set to Palette entry Zero in XnView).
BTW. Do you use API calls in your emulator? I'm looking for a reference 
of Linux and Mac API calls online. There are a lot of Windows API calls 
documented, but no Linux and Mac calls. I looking for example for the 
eqivalent of GetAsyncKeyState(). There is a demand for Retro-X on Mac 
and Linux...
>> Releasing your 3D engine for others is a great idea, I saw the Videos 
>> on YouTube, I think, you can improve the speed of line drawing by 
>> optionaly draw every second pixel of the line on screen (like 
>> "Mercenary" on Speccy).
>
>
> That would definitely help. There's quite a few more things I can do 
> to speed it up without affecting the graphics first though. It's just 
> finding the time. I think I'm relatively lucky because I don't work in 
> anything to do with software so I don't end up with programming 
> fatigue from my real life.
>
I'm not working in Software programming professionally too, it's just my 
hobby. Take nearly much time as you need... ;-)
>>> I'm also giving serious consideration to knocking up a quick BASIC 
>>> dialect to try to increase the code's reach to non-ASM people and 
>>> make it more likely that some actual titles will be released. But if 
>>> I manage that then it'll be through a PC/Mac-side compiler rather 
>>> than any sort of Sam-based interactive environment.
>>>
>> Excellent idea (that is something I was planing for Retro-X, but as 
>> Cross-Suite, with supply for multiple Machines, with modern BASIC 
>> dialect and comfortable Scintilla-Based editor. Unfortunally I was 
>> never very good at coding in Z80 assembly, and using ROM Routines), 
>> I'm looking forward to see your work, as you are much more gifted 
>> coder than I'm.
>
> Oh, this stuff is all much easier now than it must have been in the 
> 80s. And it's not just the wide array of information that is 
> accessible through the internet, when I was learning 3d I found out 
> that Elite achieves its near-solid look just by using convex objects 
> by directly asking David Braben. Let's not pretend you would have been 
> able to get that sort of help when that sort of information actually 
> had commercial value.
>
Thats right... I also use ithe Internet to do some research about 
graphics formats and image preprocessing. Asking people to help, helping 
other people... In the 80 my programs are just simple and small games, 
and Utilitys, in the 90 I learned to code better games and used first 
time my own graphics converter that I wrote on Amiga. And now with PC 
I'm stick to internet having not much free time to finish coding my 
projects.

LCD

Thomas Harte | 29 Aug 20:50

Re: Random Sam BASIC question.

> Aha. I never stop learning. That was completly new for me...
> For Acorn emulation I currently use Beeb. Just requested from the authors to
> have a binary PC file import and export-function for one of the next
> versions, like Sim Coupé. I have never heard about your emulator. Is there a
> Acorn Electron screen interpreter/viewer available? I should test the export
> of my screen converter, how it works on a emulator, but without binary
> import it is a bit hard.

Oh, my emulator is ElectrEm, at http://electrem.acornelectron.co.uk,
though it doesn't import or export binary files at present. That's
probably a more startling revelation if I also reveal that it does
import and export ASCII text format BASIC programs. I've been doing
some work to it in the last few days anyway, to improve printer
emulation (I catch and interpret Epson FX80 typographic codes but so
far haven't been doing graphics) and to fix up some bugs that have
crept in while I was adding various other improvements, so I'll look
into that.

In the meantime, I can provide a little assembly sourcefile compatible
with BeebAsm (roughly analogous to JAM or pyz80 in that it assembles
code directly to an emulator-friendly media image — see
http://www.retrosoftware.co.uk/wiki/index.php/BeebAsm) that will use
the contents of a binary file to assemble such that when you run the
resulting DFS it just puts the contents on screen. So you'd just have
to put the binary output of RetroX with the asm, run the assembler,
then launch the emulator to test.

I'm clueless about the BBC hardware (apart from the CPU, the Electron
shares nothing with the BBC on a component level), but hopefully
there's a BBC emulator that does the binary loading/saving you want.

> BTW. Do you use API calls in your emulator? I'm looking for a reference of
> Linux and Mac API calls online. There are a lot of Windows API calls
> documented, but no Linux and Mac calls. I looking for example for the
> eqivalent of GetAsyncKeyState(). There is a demand for Retro-X on Mac and
> Linux...

There are some direct Cocoa API calls, but it's very limited. ElectrEm
is primarily built around SDL, and uses that for the main display
window, for reading the keyboard and for outputting sound. On the
Windows version I run a bit of code after the SDL window has been
created to add a menubar and catch all incoming messages as a result
of that.

On OS X, I load a custom menubar before the SDL window is created,
then I've got everything wired up in Interface Builder so that the
various things in the menu trigger other dialogues. Cocoa isn't like
an MFC-on-top-of-Win32 type thing where an invisible C interface runs
some message map stuff and maps that to a C++ interface, it's a full
Objective-C system. Objective-C is 'bound' (i.e. linked) at runtime,
not compile time so you put the names of the methods that you want the
various GUI elements to call directly into the graphically created
interface, and if you've actually implemented methods with those names
then they end up being called. It's all an automatic part of the
language, not a cleanliness hack. I think this is partly why Apple
have stuck with Objective C even though C++ became the defacto object
oriented variant of C, because it binds at runtime it avoids all the
ABI compatibility problems that partly contribute to the DLL hell of
Windows past.

There are a few places where I've used Cocoa methods to launch the
standard file open/save dialogue, get the path to the application
bundle's resources folder, etc, but it really is just a few hundred
lines of the most basic GUI programming stuff while all the more
demanding game stuff is through SDL.

I think SDL itself might still be using some of the libraries that OS
X inherited from all the OSs before it, which are all deprecated now
and generally not a good idea.
http://developer.apple.com/documentation/Cocoa/ is probably the best
reference resource, but I wouldn't describe myself as an unadulterated
fan.

> Thats right... I also use ithe Internet to do some research about graphics
> formats and image preprocessing. Asking people to help, helping other
> people... In the 80 my programs are just simple and small games, and
> Utilitys, in the 90 I learned to code better games and used first time my
> own graphics converter that I wrote on Amiga. And now with PC I'm stick to
> internet having not much free time to finish coding my projects.

I don't know if I even had a computer in the 80s... I think probably
not. I was only born in 1980, so I guess my parents wanted me running
around outside instead, which I did and seem to remember very much
enjoying. I had a secondhand Electron for about a year before my Sam,
then skipped the 16 bits entirely to go PC and then Mac. The internet,
which I think we first got a link to in 1996 or 1997, was a
revelation.

I think the only thing of any length I ever wrote on my real Sam was
an Outwrite clone in BASIC. It was very slow indeed, and couldn't
print.

Leszek Chmielewski | 9 Sep 00:03

Re: Random Sam BASIC question.

Sorry, I was very busy improving my Retro-X in the last time. I found 
more and more messages from Sam-users in my gmail spam directory...

Thomas Harte schrieb:
>> Aha. I never stop learning. That was completly new for me...
>> For Acorn emulation I currently use Beeb. Just requested from the authors to
>> have a binary PC file import and export-function for one of the next
>> versions, like Sim Coupé. I have never heard about your emulator. Is there a
>> Acorn Electron screen interpreter/viewer available? I should test the export
>> of my screen converter, how it works on a emulator, but without binary
>> import it is a bit hard.
>>     
>
> Oh, my emulator is ElectrEm, at http://electrem.acornelectron.co.uk,
> though it doesn't import or export binary files at present. That's
> probably a more startling revelation if I also reveal that it does
> import and export ASCII text format BASIC programs. I've been doing
> some work to it in the last few days anyway, to improve printer
> emulation (I catch and interpret Epson FX80 typographic codes but so
> far haven't been doing graphics) and to fix up some bugs that have
> crept in while I was adding various other improvements, so I'll look
> into that.
>
>   
Even if it does not import binary files, your link helped me to get some 
important documents about Acorn. Now my Retro-X is also able to convert 
images to all Acorn graphical modes (0,1,2,4,5). I requested the binary 
import/export feature for Beeb Emulator and the latest release got these 
features now.
Your Tokeniser is a great idea...
> In the meantime, I can provide a little assembly sourcefile compatible
> with BeebAsm (roughly analogous to JAM or pyz80 in that it assembles
> code directly to an emulator-friendly media image — see
> http://www.retrosoftware.co.uk/wiki/index.php/BeebAsm) that will use
> the contents of a binary file to assemble such that when you run the
> resulting DFS it just puts the contents on screen. So you'd just have
> to put the binary output of RetroX with the asm, run the assembler,
> then launch the emulator to test.
>
>   
This would be a nice feature if I can build it into my program, to 
generate fully executable files, eventually wuith compressor. At moment 
I do not know the TAP format of Acorn and also no details about disc 
image formats, but because there is much to do with other stuff, this is 
something for future.
Anyway I'm happy that Beeb's import works fine. I generate my files and 
can import them in debugger with fr xxxx 3000 command (xxx=filename, 
3000 replaced by 5800 in modes with 10240 bytes screen size)
> I'm clueless about the BBC hardware (apart from the CPU, the Electron
> shares nothing with the BBC on a component level), but hopefully
> there's a BBC emulator that does the binary loading/saving you want.
>
>   
Now yes!
>> BTW. Do you use API calls in your emulator? I'm looking for a reference of
>> Linux and Mac API calls online. There are a lot of Windows API calls
>> documented, but no Linux and Mac calls. I looking for example for the
>> eqivalent of GetAsyncKeyState(). There is a demand for Retro-X on Mac and
>> Linux...
>>     
>
>
> I think SDL itself might still be using some of the libraries that OS
> X inherited from all the OSs before it, which are all deprecated now
> and generally not a good idea.
> http://developer.apple.com/documentation/Cocoa/ is probably the best
> reference resource, but I wouldn't describe myself as an unadulterated
> fan.
>
>   
Cocoa looks like it would be a nice library, but because I do not use C 
or C++ but PureBasic, so I should write a wrapper first. Anyway this is 
a good starting point for the conversion to other OSes.
>> Thats right... I also use ithe Internet to do some research about graphics
>> formats and image preprocessing. Asking people to help, helping other
>> people... In the 80 my programs are just simple and small games, and
>> Utilitys, in the 90 I learned to code better games and used first time my
>> own graphics converter that I wrote on Amiga. And now with PC I'm stick to
>> internet having not much free time to finish coding my projects.
>>     
>
> I don't know if I even had a computer in the 80s... I think probably
> not. I was only born in 1980, so I guess my parents wanted me running
> around outside instead, which I did and seem to remember very much
> enjoying. I had a secondhand Electron for about a year before my Sam,
> then skipped the 16 bits entirely to go PC and then Mac. The internet,
> which I think we first got a link to in 1996 or 1997, was a
> revelation.
>
>   
I was born in 1971, so my Home computer experience begann 1985 with a 
Spectrum 48+, then I moved to Spectrum 128, In late 80's I had a Amiga 
500, then I moved again to Spectrum and 1990 I purchased my SAM Coupé, 
then 1995 my first PC. I do never like to play outside, so I prefered to 
play with my computers. I think, I got Internet in 1998.
> I think the only thing of any length I ever wrote on my real Sam was
> an Outwrite clone in BASIC. It was very slow indeed, and couldn't
> print.
>
>   
That sounds cool! I wrote some SAM games like "Heavier than Metal", 
"Ultra Reflect", "Reverse Side" and made a lot of tools demos and 
Utilitys for SAM (The funny Vector Animations published on FRED 33 and 
34) and Spectrum.

LCD

James R Curry | 29 Aug 15:17

Re: Random Sam BASIC question.

On Thu, Aug 28, 2008 at 2:22 PM, Leszek Chmielewski <retrozx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
SAM adv. technical manual says:

10 LET A=IN 252 BAND 31
20 LET BASE=(A+1)*16384

BASE=Start of Screen


Thanks.  I found the answer right after I posted in the technical manual.
It certainly seems to have started conversation, however.  So, hurrah!

Ah, for the halcyon days of this being second nature...

I was trying to explain to a co-worker how the Spectrum's screen memory was laid out, and when I realised that I had Simcoupe on a work machine, it was easier to knock together a SAM BASIC program to demonstrate in Mode 1.


--
James R Curry
8bit-snUiKen5ueM0wvh7NyEbwA@public.gmane.org

Gmane