While I'm on a role, I might as well get to my next concern--For people who are more than just users, but aren't totally comfortable with microcode, the O/S needs a user-friendly programming language; one that doesn't require memory allocation, declaration of simple variables, or keeping track of case; one that can put a point on a screen with a single command.

Yeah, I'm talking BASIC. Maybe even run it directly AS DOS; just keep AREXX and batch files--even the old O/S keywords--for compatibility. frankly, having to swap between 'em is a real--no, I won't say that, I liked my dog Baby....

But....As far as I can tell, the best general use BASIC was HiSoft II; not fully up to a modern environment.

First, there is at least 1 bug; not fixed in Maxon BASIC 3:



A$ = "42" 'if it's good enough for HiSoft, it's good enough for me

A% = VAL(A$)
AFFP! = VAL(A$)
A& = VAL(A$)
A! = VAL(A$)
A# = VAL(A$)

AInt$ = MKI$(A%)
AFFP$ = MKFFP$(AFFP!)
ALong$ = MKL$(A&)
ASing$ = MKS$(A!)
ADub$ = MKD$(A#)

? CVI(AInt$),CVL(ALong$),CVS(ASing$),CVFFP(AFFP$),CVD(ADub$)
? CVS(AFFP$),CVFFP(ASing$)

? "Int : ";:HexDumpString AInt$
? "Long: ";:HexDumpString ALong$
? "Sing: ";:HexDumpString ASing$
? "FFP : ";:HexDumpString AFFP$
? "Dbl: ";:HexDumpString ADub$

IF ASing$ = AFFP$ THEN

PRINT "FAIL! ASing$ should NOT be the same as AFFP$!"

ELSE

PRINT "PASS! Compiler knows the difference between IEEE and FFP!"

END IF

ALptr& = VARPTR(A!)
ASing$ = HEX$(PEEKL(ALptr&))

DumpHexString ASing$
'?BIN$(&hA8)

'=========

END

SUB HexDumpString(z$)

FOR a = 1 TO LEN(z$)
'Q$ = "00"

T$ = HEX$(ASC(MID$(z$,a,1)))
IF LEN(t$) = 1 THEN T$ = "0" + T$
? T$;" ";
NEXT
?
END SUB

SUB DumpHexString(z$)

FOR a = 1 TO LEN(z$) STEP 2
? (MID$(z$,a,2)); " ";
NEXT
?
END SUB



Works in HiSoft BASIC Professional, but not HiSoft BASIC II or Maxon BASIC 3.

Anyone run into any other Bugs?

Then we have to update it to the new O/S and hardware, so 64 bits is a must; let the O/S deal with multiple processors. Though it would be nice to specify that all 400 processor get used on an FFT of a 512x512 image....

So, what else?

How about a few more system variables/constants, like QT$+CHR$(34) or Pi=3.1425926....

Just ignore a call to open a library if it's already done?

"Shell(x$)? (GWBASIC has it, why don't we?)

ability to read the various tokenized formats, going back to, say, TRS-80 BASIC Level 2(M$'s first BASIC)

I understand that there are some legacy induced problems, some C .libraries that don't open, ArgV(o) not passed, maybe some others, there because that's the way M$ did it.

Fix that.

More system calls; so that ArgC&== C's long ArgC and ArgV$() is equal to * char ArgV[ArgC]
in C. (apologies if I mangled the C, I can read it much better than I write it...)

Matrix operations

-P-code--you can take the Mac compiled version, and run it in Window$ or Linux, as well as whatever the Amiga morphs into (pun intended)

In the library compile version, only those functions actually used get included.

And a WAY more advanced editor.....


So? Slings, Arrows(), actual ideas?

@pgf_666

As a fellow programmer who is working on a "basic" scripting language for an employer, can "feel your consternation" at these deficiencies.

Working to keep up with Moore's Law for hardware feels like an insurmountable task, but it my pleasure to see to it that the bug list becomes shorter.

Good luck exciting a programmer to work on your list.

_________________
..effects of civilization upon...nature, the growing gap between what education was supposed to accomplish and what it consisted of, the national debt and...high taxes, the problem of the excess cost of medical care -- Philip Wylie, 1951

@pgf_666

When I first read this I thought, "You want Python," but what do I know.

Quote:

For people who are more than just users, but aren't totally comfortable with microcode, the O/S needs a user-friendly programming language; one that doesn't require memory allocation, declaration of simple variables, or keeping track of case; one that can put a point on a screen with a single command.

Maybe I misunderstand you, but I'm not aware of a single language that requires memory allocation, and I've used quite a few. Even C and Java don't require memory allocation if you're content to work with fixed arrays and forego their more powerful features (and lots of real-time programmers do precisely that with C; e.g., my father, now-retired). A number of languages actively discourage memory allocation; Bjarne Strousroup has said somewhere that one of the goals of C++ was to minimize the amount of work with pointers that C requires; hence the introduction of passing arguments by reference (which Pascal and other languages had around the same time that C was released).

I guess you're referring to the fact that, for instance, in Amiga C you have to allocate memory for windows and the like. Technically, you do that in BASIC, too; it's just that in the best-case scenario the BASIC interpreter hides the allocation from you.

Many modern languages let you avoid declaring the type of a variable: Python doesn't require you to declare type at all, but that does lead to problems. C++ has the auto keyword to request inference when possible, and given the ugliness of its type signatures, you probably want to use it as much as possible. Kotlin will automatically infer it, as will Nim.

If I read you correctly (and I may not) you seem to think that BASIC does not require you to declare a variable's type, but in fact, it does, as I will explain in a moment. Even worse, it requires you to repeat the type every time you use the variable. Whenever you write the $ symbol, you are (re)declaring the variable's type to be string; the & symbol (re)declares the variable's type to be pointer; anything without either symbol is numeric.

Anyway, the more I read this, the more I think you really are itching for some sort of Python, but you're pretty adamant about case-sensitivity so never mind.

Quote:

Just ignore a call to open a library if it's already done?

There are languages that do this for you. I once used a version of Modula-2 on the Amiga that automatically opened a library for you if you used any of the commands in a particular module, so that you didn't have to keep track of whether it was open and all that. I'm pretty sure it was Tom Breeden's M2 compiler, though I'm not sure. I don't think they're available on the Amiga, but I'm pretty sure Ada and Nim would do the same, as long as the corresponding package/module were set up properly, and probably Java and Kotlin, too, though in these latter cases the setup can be hidden in compilation configuration files that someone has to set up.

I think I recall reading that the compiler for AmigaOS4 automatically opens at least a few libraries for C programs, but I may be misremembering.

A small correction to what you wrote: TRS-80 BASIC Level II was by no means Microsoft's first BASIC. They were doing it well before then, from the Altair days in fact. That's what made them famous.

_________________
I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me.

@ggw

You seem to understand; as for the programmer--details, details...

@simplex

OK, Python is interesting, but Caps & I have a long-standing feud....

I'm not just talking about Alloc(); int a allocates 2 bytes. In basic, if I write A=10, the program allocates 4 bytes as a short float unless i use something like DEFINT a to tell it otherwise; sort of a more flexible version of the way FORTRAN does it. If I write a(5)=2, then a() is dimensioned as a(10). Not my job. The nearest C comes to this kind of help is to consider as a general variable anything allocated before main(). Better than DIN SHARED in some ways, but not as flexible...

Altair? Altair? ALTAIR? I thought that name was a myth mothers used to scare their kids with: "Be good. or Santa will take your XBox and leave an Altair in its place!"

Did I mention that it should read undigested .fd files as well?

I'm a (High-level) programmer, I can handle AREXX and C, but many potential future customers get lost in a .bat file; If the South--ah, sorry, the Amiga!--is truly to rise again, we need to look out for these people--remember, the synonym for 'user' is 'customer'....

The best solution is a WINE port so that you can code in VB.net!

https://www.mono-project.com/

Also, the compiler:
https://github.com/dotnet/roslyn

Quote:

Roslyn provides open-source C# and Visual Basic compilers with rich code analysis APIs. It enables building code analysis tools with the same APIs that are used by Visual Studio.

EDIT: added mono reference

Last edited by Lou on 18-Dec-2018 at 04:39 PM.
Last edited by Lou on 18-Dec-2018 at 02:10 PM.

Quote:

simplex wrote: I think I recall reading that the compiler for AmigaOS4 automatically opens at least a few libraries for C programs, but I may be misremembering.

Amiga C compiler standard startup code will usually setup SysBase and DOSBase pointers (includes opening and closing dos.library). Some Amiga compilers can automatically open and close Amiga libraries (vbcc auto.lib linking with -lauto or -lautos on the command line). See chapter 12.4.9 page 76 of the vbcc manual for details.

http://server.owl.de/~frank/vbcc/docs/vbcc.pdf

@pgf_666

Quote:

I'm not just talking about Alloc(); int a allocates 2 bytes. In basic, if I write A=10, the program allocates 4 bytes as a short float unless i use something like DEFINT a to tell it otherwise; sort of a more flexible version of the way FORTRAN does it. If I write a(5)=2, then a() is dimensioned as a(10). Not my job. The nearest C comes to this kind of help is to consider as a general variable anything allocated before main(). Better than DIN SHARED in some ways, but not as flexible...

I'm really not following you here.

At first you complained that you wanted a language that didn't require memory allocation. The natural assumption is that you're talking about "dynamic" memory on the heap, because any program at all allocates at least some "static" memory on the stack. In the early days of Amiga it was not uncommon to have to modify something (I forget exactly what) so that a program would start with a larger stack.

But now you say, "In basic, if I write A=10, the program allocates 4 bytes" as if that isn't a memory allocation; it is. Similarly "a(5)=2"; that allocates memory. Any variable in BASIC allocates memory.

I have the impression you actually mean that you don't want to have to declare variables' types, but as I pointed out earlier, you have to do that in BASIC every time you use the variable, and in a rather ugly way, too: $ is string, & is pointer, lack of either is numeric. Whereas in C I write "int a" and "a" is an int from then until end of scope; in C++ I write "string a" and a is a string from then until end of scope, so that I don't have to write "a$" or "string a" every time I simply want to write "a".

But I honestly don't know what you mean.

_________________
I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me.

@simplex
ARexx has typeless variables. Variables are stored as strings and converted to the type required by operations and functions. While this works pretty well, it is less efficient (more conversions) and less readable (untyped variables). I wish ARexx could be extended to allow typed variables like in C while retaining support for the default typeless variables (best of both worlds).

@matthey

Quote:

I wish ARexx could be extended to allow typed variables like in C while retaining support for the default typeless variables (best of both worlds).

I repeat and extend: Python/Cython

I think there is another language that does something like this, interpreted no less, but I can't for the life of me remember it at the moment.

I've used ARexx a long time ago and I think I liked it once I figured it out, much as the language for installer scripts (based on LISP IIRC). A drawback of Rexx is that it just didn't catch fire in the industry. Python has. I understand the appeal of BASIC to those who used it 30-40 years ago (I did) but its limitations are just too much now. Python is easier IMOH, and better in pretty much every way, such as case-sensitivity.

_________________
I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me.

Quote:

simplex wrote: I've used ARexx a long time ago and I think I liked it once I figured it out, much as the language for installer scripts (based on LISP IIRC). A drawback of Rexx is that it just didn't catch fire in the industry. Python has. I understand the appeal of BASIC to those who used it 30-40 years ago (I did) but its limitations are just too much now. Python is easier IMOH, and better in pretty much every way, such as case-sensitivity.

ARexx did catch on on the Amiga. It was used extensively for productivity software from ADPRO, ImageFX, CygnusED, Scala, to the Video Toaster and all its utilities. It provided inter-process communication and scripting unsurpassed on any other platform I'm aware of. There was even a compiler created for ARexx. The problem is the Amiga faded from relevance.

Last edited by matthey on 18-Dec-2018 at 10:17 PM.

@matthey

Quote:

ARexx did catch on on the Amiga.

Perhaps I was unclear, but I meant, "catch on industry-wide," the way Python did (and another scripting language that starts with P that I won't otherwise mention, especially as it now seems to be fading hard). Even at its height, the Amiga was at best a bit player, a minority platform -- a visionary platform, yes, but a minority nonetheless.

_________________
I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me.

@pgf_666

Try AmiBlitz3 on sourceforge

https://sourceforge.net/projects/amiblitz3/

AmiBlitz is written in AmiBlitz, and is opensource so if you find bugs you can fix them.

How deep you want to delve into amigaos when you code is up to you, you can use the built in blitz commands or delve into system libraries, no opening required. eg, to put a pixel on screen via graphics library you would use: writepixel_(rp,x,y) or in blitz: plot(x,y)

AmiBlitz3 has a decent IDE with auto case correction on all commands, so give it a try

Last edited by Severin on 18-Dec-2018 at 10:56 PM.

_________________
OS4 Rocks
X1000 beta tester, Sam440 Flex (733)

Visit the Official OS4 Support Site for more help.

It may be that your sole purpose is to serve as a warning to others.

@simplex

Quote:

When I first read this I thought, "You want Python," but what do I know.

You beat me to it.

Quote:

A drawback of Rexx is that it just didn't catch fire in the industry.

Nor would it now, I think. It has a mechanism for formatted output that is completely different to everything else I have ever used. It's like Bourne shell in that every time I use it, have to go back and figure it out again.

Last edited by bison on 18-Dec-2018 at 11:03 PM.

_________________
"Unix is supposed to fix that." -- Jay Miner

@pgf_666

Well I'm working on "Amos Kittens", so you run Amos program on AmigaOS4.1, Amos Basic is ok language, but its maybe not modern, and it might considered a bit of a toy basic, as was not designed for console. But if you can ignore that, Amos has some thing called "Window" that is basically a text console on top of graphic screen. In the start "Amos Kittens" did support the Amiga consoles, but as project continued to progress, it going in the direction of original Amos a bit like game engine. You know something also deals with joysticks, moving objects, animation, double buffering and stuff like that.

There are some small improvements over original design, but I'm not aiming at modernizing it, it more like side effect of coding in C, and writing structured code, that results in concepts that can be reused, that again results in improvements.

Some of the improvements In AMOS Kittens.

* You are allowed to dim array again, if the array is too small.
* Procedure can have 3 return values of different types as the same time, String, float and integer numbers, using Param#, Param$ and Param command to collect the return values, works with "End Proc" and "Pop Proc".
* Amos Kittens runs in chunky mode, so there are no 1,2,3,4,5,6 bit screens modes, all screen modes are promoted to 8 bit, resulting in 256 colors instead typical 64 colors lookup table original Amos. This also effects bobs, sprites, blocks, c blocks and all primitive draw commands.
* System friendly, result now support USB gamepads, and execcall forbid and permit now don't freeze Amos Kittens like, Amos Pro does, so now you can do some advanced programing from AMOS.
* Amos menus can be promoted to AmigaOS menus, like normal programs.

Stuff that is planned:

* Icnonify, this be triggered by "Amos To Back", or iconification icon in window title.
* AHI Support, use any sound card you like, no more Paula only.

Last edited by NutsAboutAmiga on 21-Dec-2018 at 12:15 AM.
Last edited by NutsAboutAmiga on 19-Dec-2018 at 09:52 PM.
Last edited by NutsAboutAmiga on 19-Dec-2018 at 09:48 PM.
Last edited by NutsAboutAmiga on 19-Dec-2018 at 09:37 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

Quote:

NutsAboutAmiga wrote: Well I'm working on "Amos Kittens", ...

Interesting feature list:
http://amigablogs.net/feed/2018/05/amos-kittens-new-amos-interpreter-amigaos41

I don't know if you have written it in PPC Assembler or in C, but if you can provide a portability to AOS3, MOS and AROS you could create a easy to use X-Plattform language. Even the AOS4 part would benefit from Basic programs, written for the other platforms.

@OneTimer1

"I don't know if you have written it in PPC Assembler or in C"

its written in pure C, so it portable,
"but if you can provide a portability to AOS3, MOS and AROS"

Well it is portable already, as in ready for someone to start making the changes to make it run on MOS, OS3.

"AORS" mostly runs on INTEL/AMD and that is not an easy target. (AMOS was written for Big endian CPU's like 680x0 and I'm working big endian cpu the PowerPC so PowerPC or the 680x0 is easy targets for Amos Kittens.)

I think Deek,Leek,Doke, Loke command should operate in Big endian mode on the INTEL/AMD, so AMOS programer don't need to worry about this. when writing AMOS programs.

"You could create a easy to use X-Plattform language. "

Well that is the idea, token files can from the bases for cross platform games, if people are willing to share there program code, if not, it I guess you need encrypt, code somehow, you can also embedded token and link this into a binary to distributed on platform target. There are some details to be worked out.

"Even the AOS4 part would benefit from Basic programs, written for the other platforms."

Well I don't consider AmigsOS 3.x a different platform, I do consider it an older platform, this what most AMOS games are written for now, but it might be things turn around and people start making games for AmigaOS 4.x, that few small changes also works on OS 3.x.

Last edited by NutsAboutAmiga on 21-Dec-2018 at 12:03 AM.
Last edited by NutsAboutAmiga on 21-Dec-2018 at 12:00 AM.
Last edited by NutsAboutAmiga on 20-Dec-2018 at 09:24 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

Quote:

NutsAboutAmiga wrote: its written in pure C, so it portable, "but if you can provide a portability to AOS3, MOS and AROS"

Nice

Quote:

"AORS" mostly runs on INTEL/AMD and that is not an easy target. I think Deek,Leek,Doke, Loke command should operate in Big endian mode on the INTEL/AMD, so AMOS programer don't need to worry about this. when writing AMOS programs.

Byte ordering problems are a never ending story.

Especially because Amos may not have the abstractions to come around them.

If you are accessing a table with 32bit (or 16bit) values you should always know if they are addresses, plain binary Data or RGB values.

You will always fail, it only matters if you fail in compatibility with other platforms or with your onw system accesses.

Last edited by OneTimer1 on 21-Dec-2018 at 03:02 PM.

@OneTimer1

Quote:

Especially because Amos may not have the abstractions to come around them.

Assembler does have big end little endian instructions, but this unknown to C/C++ that does not have data types of big endian, little endian pointers.

In addition, it interesting to know that "int" used be 16 bit, but was upgraded to 32 bit, this was of course a horrible mistake, so they introduced the int32_t and int16_t types, to make a clear difference between the two. The mistake they was to not define an int32be_t, int32le_t and make the compiler sort it out.

I guess the made the same mistake twice, but the second time, intel was dominant in the market and so no one really cared, IBM/Apple too stupid to see the writing on the wall.

Quote:

you should always know if they are addresses, plain binary Data or RGB values.

The computer does know the difference between Data, RGB or Image, cat or a dog. Or some other stuff put in there it's all binary data, however there is difference between program code and data, as program code is write protected, while data is not. (Well at least on AmigaOS4.1), then you might say what about INT's as declared in program, well INT's declared in program are allocated on the stack, and not in program code.

This is the behavior of the C compiler.

The important thing is not how it read in memory, but how it was written to disk; so if you saved some memory to disk, and loaded it, you need to know the format of file you have loaded.

All the ABK files are big endian format, IFF (sound, images, and prefs files) files are big endian format, and everything else that comes from Amiga computers. But if you try to load wav files saved on INTEL/AMD computer then you need to convert it before you can use it, but as most WAV files are mostly little endian you make pretty good guess about its format, without reading header of wav file.

The clear solution to this is not try to redefine the existing commands, but instead keep them as they are, and if you like DokeLe, DeekLe, LeekLe, LokeLe, and then it better to add this as extra commands. Not mess with what we have.

Last edited by NutsAboutAmiga on 21-Dec-2018 at 06:03 PM.
Last edited by NutsAboutAmiga on 21-Dec-2018 at 06:02 PM.
Last edited by NutsAboutAmiga on 21-Dec-2018 at 05:59 PM.
Last edited by NutsAboutAmiga on 21-Dec-2018 at 05:04 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

Quote:

NutsAboutAmiga wrote: Assembler does have big end little endian instructions, but this unknown to C/C++ that does not have data types of big endian, little endian pointers.

Endian specific datatypes would be needed for most datatypes, not just pointers. A pointer as well as the data it points to can have different endianness. I'm not sure it is wise to add so many endian variations of datatypes. It may be better to have C standard functions of the __builtin_bswapX() functions and even they could be an optional library. My __builtin link library for vbcc makes these functions optional allowing for modularity of the compiler which saves resources.

Quote:

In addition, it interesting to know that "int" used be 16 bit, but was upgraded to 32 bit, this was of course a horrible mistake, so they introduced the int32_t and int16_t types, to make a clear difference between the two. The mistake they was to not define an int32be_t, int32le_t and make the compiler sort it out.

I don't believe the "int" datatype specification for size has changed in any new C standards. Only a minimum size is specified for "int" which is -32767 to 32767 (16 bits two's complement).

https://en.wikipedia.org/wiki/C_data_types

What was upgraded was CPU 64 bit data models.

https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models

Data models specify the default size for "int". An "int" on a 64 bit CPU may now be 64 bits or still 32 bits but the minimum size of "int" is still 16 bits. An "int" on a 32 bit CPU may be 32 bits or 16 bits but the minimum size of "int" is still 16 bits. An "int" on an 8 bit CPU is likely going to be 16 bits because it can't be 8 bits. A C programmer writing portable code should allow for an "int" to be as small as 16 bits (yes, there is a lot of code that would fail). Before C99, programmers had to use sizeof() with conditional code to know the size of datatypes but this was slow, annoying and error prone. The specified sizes like intN_t give the exact width needed even if it is slower, intfastN_t allows to specify the fastest datatype with the minimum width and intleastN_t allows to specify a minimum width while saving space. They are not replacements for "int" but more restrained datatypes for making code more concise and portable.

Quote:

I guess the made the same mistake twice, but the second time, intel was dominant in the market and so no one really cared, IBM/Apple too stupid to see the writing on the wall. Quote: you should always know if they are addresses, plain binary Data or RGB values. The computer does know the difference between Data, RGB or Image, cat or a dog. Or some other stuff put in there it's all binary data, however there is difference between program code and data, as program code is write protected, while data is not. (Well at least on AmigaOS4.1), then you might say what about INT's as declared in program, well INT's declared in program are allocated on the stack, and not in program code.

Did you mean to say the computer does "not" know the difference between data?

Local variables and non-constant data are usually allocated on the stack (or stay register only on higher optimization levels) while global variables and some data usually are allocated in the program sections (Code/Text, Data, BSS). Data constants commonly are placed in the Code/Text section (although not always with modern security measures) but this section can still be write protected. Data sections can commonly optionally be write protected on systems with memory protection.

Quote:

This is the behavior of the C compiler. The important thing is not how it read in memory, but how it was written to disk; so if you saved some memory to disk, and loaded it, you need to know the format of file you have loaded. All the ABK files are big endian format, IFF (sound, images, and prefs files) files are big endian format, and everything else that comes from Amiga computers. But if you try to load wav files saved on INTEL/AMD computer then you need to convert it before you can use it, but as most WAV files are mostly little endian you make pretty good guess about its format, without reading header of wav file. The clear solution to this is not try to redefine the existing commands, but instead keep them as they are, and if you like DokeLe, DeekLe, LeekLe, LokeLe, and then it better to add this as extra commands. Not mess with what we have.

There are reasons to leave data in memory in another endian format although it is not common. Emulators are an example. Sometimes there is an advantage to accessing data in another endianess. Standard and simple endianess conversion functions would probably suffice in most cases.

@matthey

An example of some code, might think someone written in AMOS Pro or Amos The Creator.

Reserve As Chip Data 7,1024
BLOAD "SomeData",7
adr = Start(7)
fileID = Leek(adr)
chunkSize = Leek(adr+4)

BLOAD does know the format file "SomeData", it knows it file, load into a bank.
Leek is big endian on 680x0, so we can assume the file is big endian, if the file is little endian, we assume that programmer already did take care of the conversion in the Basic code.

So this way think it's better to let Leek, Leke be what they are.

Well some time developers might write something like

AREG(0)=varptr(value)
DREG(0)=12
e=ExecCall(-LVO)

Calling a exec routine, from emulated Exce.library,

or write some data into SomeData bank, you don't wont to confuse this with putting little endian data into it.

Last edited by NutsAboutAmiga on 22-Dec-2018 at 03:09 PM.
Last edited by NutsAboutAmiga on 22-Dec-2018 at 12:49 PM.
Last edited by NutsAboutAmiga on 22-Dec-2018 at 12:49 PM.
Last edited by NutsAboutAmiga on 22-Dec-2018 at 12:48 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS