 Previous Messages |
Posted By
MMS
on 2019-12-20
15:28:41
 |  Re: Commodore Basic's oddnesses
Hi Folks,
Just digging out this old thread, I found a really good video about speedups and especially using integers vs floating point:
https://www.youtube.com/watch?v=wo14rDnGUbY
|
|
Posted By
gerliczer
on 2015-10-30
08:12:09
| Re: Commodore Basic's oddnesses
You are welcome JamesC. Although I think you should thank not me but the Commodore software engineers. All I did was connecting the obvious dots. The best in it is that, I guess, this should work exactly the same on all Commodore 8bit machines except using system specific memory locations like the tape buffer.
|
|
Posted By
JamesC
on 2015-10-29
15:21:26
| Re: Commodore Basic's oddnesses
Tramiel's biggest investor, other than himself, was Irving Gould. Gould wanted dividends and a high stock price, both of which go down when a company invests in R&D. 
Gerliczer, thank you for the Kernal setup routines. 
|
|
Posted By
gerliczer
on 2015-10-29
14:40:35
| Re: Commodore Basic's oddnesses
Well, this is not oddity. It is managerial short-sightedness or negligence. Nowadays such CEOs, CFOs and CTOs would be chased out of any company. I suppose, investors back then were not as aggressive as today.
|
|
Posted By
Litwr
on 2015-10-29
13:57:21
| Re: Commodore Basic's oddnesses
Commodore itself had an oddity - they didn't upgrade things. They might force the usage of C1581 by releasing games (like Ultima 6) on 3.5" disks... They ignored Moore's law producing 6502 without modification during almost 20 years. Try to imagine C64 which uses 6502 with 6 MHz. This CPU might use C+4 technology to give 1MHz cycles to VIC and SID and work at IBM AT speed! They might also add one or two segment registers and make 1MB or more RAM addressable with 100% compatibility with old software... It is the mystery why they didn't make cheaper and compatible with IEC bus version of SFD1001 at the mid 80s?... However the same oddity had Sinclair and a lot of other microcomputer producers.
|
|
Posted By
gerliczer
on 2015-10-29
13:18:33
| Re: Commodore Basic's oddnesses
There's also the 1581 route.
|
|
Posted By
MMS
on 2015-10-29
12:51:06
| Re: Commodore Basic's oddnesses
Illustrated adventure with nice full screen (almost) photorealistic pictures
The aim is to look better than even the Magnetic Scroll games, that could be quite a challange, but what will be plus on the look, will be a minus on complexity
No real parser. (try to do some icon based control with sprite cursor emulation, but duh, slow as hell. RS232 mouse support is a still a questionmark due to slow driver)
I have all the maps, concept art, ingame special characters, fonts, and most of the unconverted GFX, but even if I break it into 3 parts (like the movie...) it needs significant disc space.
The only real limitation is the disc space, and the number of pictures that can be stored on a D64 without compression, I do not want disc side control, file loading error handling and swapping. Because of it I am a little stuck, as even the first story part does not fit into D64
(would be great to have support of IEE4888 SFD1001 with 1MB disc side, haha).
There is no real memory efficient and quick enough GFX compression method with Commodore BASIC. Even via assembly it is a big task to get something useful, not to speak about the complexity of proper compression. I went deep inside LZW compression method, but there is no real easy way...
|
|
Posted By
gerliczer
on 2015-10-29
13:20:33
| Re: Commodore Basic's oddnesses
Impovement (by Capt. Obvious):
30 FN$="DORKDAVE":FN=LEN(FN$)
40 FORI=1TOFN:POKETB-1+I,ASC(MID$(FN$,I,1)):NEXT
60 POKESA,FN:POKESX,TBAND255:POKESY,TB/256:SYSDEC("FFBD")
So, when may we expect that illustrated adventure? Or will that be an RPG?
|
|
Posted By
MMS
on 2015-10-28
16:04:23
| Re: Commodore Basic's oddnesses
WOW, thanks!!! It is just great! I fully understand now how it works.
And it really completely solved the GFX LOADING issue that prevented structured programming I wanted to realize.
This is the very first time I see a KERNAL routine called from BASIC, and it looks just great and neat!
(I will check it with Plus4Emu)
It could be changed to a very nice general loader subroutine, that could be called after some initial settings on global variables called with GOSUB.
|
|
Posted By
gerliczer
on 2015-10-27
17:21:38
| Re: Commodore Basic's oddnesses
Hi MMS,
I found this loading task intriguing, so I experimented with it in BASIC a little bit.
10 SA=DEC("07F2"):SX=SA+1:SY=SX+1:SR=SY+1
20 TB=DEC("0333")
30 POKETB,68:POKETB+1,79:POKETB+2,82:POKETB+3,75
40 POKETB+4,68:POKETB+5,65:POKETB+6,86:POKETB+7,69
50 POKESA,0:POKESX,8:POKESY,0:SYSDEC("FFBA")
60 POKESA,8:POKESX,TBAND255:POKESY,TB/256:SYSDEC("FFBD")
70 POKESA,0:POKESX,1:POKESY,32:SYSDEC("FFD5")
80 PRINT"1234"
Assuming that the recent Dork Dave and The Dirty Trick disk is in drive 8, the short code above loads the loader file (DORKDAVE) to $2001. Not that easy as simply typing LOAD, but it doesn't restart the program therefore no need to do that variable trick.
If you'd like to discuss it in detail, I can give you explanation. Although proper operation is not guaranteed since it was tested only in YAPE.
|
|
Posted By
MMS
on 2015-10-26
20:12:16
| Re: Commodore Basic's oddnesses
Thanks, it was a nice example. although I will need to load several GFXs at a certain point, and the őrogram should countinue after that.
Just downloaded a big bunch of C64 programming books, certainly they will be full of POKEs and PEEKS, but may find some nice routines too.
Some 3000pages to dig through, hehehe
http://www.bombjack.org/commodore/books.htm
|
|
Posted By
gerliczer
on 2015-10-26
16:47:03
| Re: Commodore Basic's oddnesses
@JamesC
You are right. I should have written ON GOSUB. 
|
|
Posted By
JamesC
on 2015-10-26
14:38:20
| Re: Commodore Basic's oddnesses
@Gerliczer - I was trying to illustrate to MMS how GOTO is not needed.
|
|
Posted By
gerliczer
on 2015-10-26
11:36:06
| Re: Commodore Basic's oddnesses
Or you may even use ON GOTO.
|
|
Posted By
JamesC
on 2015-10-25
21:49:50
| Re: Commodore Basic's oddnesses
@Gerliczer: yes, those are H2G2 references.
@Litwr: it is just that, Knuth's opinion. But his opinion will crash a CBM 8-bit if used repeatedly. Is it possible you were thinking of a DO:LOOP with an EXIT? This will remove the running loop from the stack, allowing you to exit without memory issues.
@MMS: you can use Kernal routines to load a file from a running program. Or you can set a load variable, then load your graphics, font, etc at the start of execution:
10 IF L=0 THEN L=1 : GRAPHIC 1,1 : GRAPHIC 0 : LOAD "GRAPHICSCREEN",8,1
11 IF L=1 THEN L=2 : LOAD "FONT",8,1
12 IF L=2 THEN L=3 : LOAD "POINTER IRQ",8,1
13 : REM INSERT POKES FOR TED TO USE CUSTOM FONT
14 : REM INSERT POKES FOR MOUSE-LIKE POINTER IRQ TO EXECUTE
15 (program starts at this point)
|
|
Posted By
MMS
on 2015-10-25
15:29:52
| Re: Commodore Basic's oddnesses
I like Pascal and the structured programming, but as far as I see, the Pascal implementations on Plussy not so good. (C I do not like so much and did not tested the CC65, as seem some main libraries are missing).
Also at the first sight the V3.5 well equipped to support structured programming with WHILE/DO etc, unfortunately in several cases the V3.5 requires GOTO. For exampla just loading a picture into the memory restarts the program, and only with preset values and with GOTO you can continue the program as it should be. Or the KERNAL may help here in BASIC too?
|
|
Posted By
Litwr
on 2015-10-24
12:08:35
| Re: Commodore Basic's oddnesses
@JamesC, @gerliczer Thank you very much for help. I learn English since teens. I am almost sure now that it is impossible for a foreigner to know it very well. It was popular opinion in SU that English is very easy. However all my teachers knew it very poor. I know woman who studied it in the special English school(!), read a lot of textbooks, but she knows only a small part of the language.
So it looks like I gave improper name for the topic. Sorry.
@JamesC Your example is excellent! My example is just a pure syntax check, no semantics at all. It is a Donald Knuth's opinion that GOTO is the best way to exit from the deeply nested loops. Some languages allow to use BREAK and CONTINUE statements with the integer argument for this case.
|
|
Posted By
gerliczer
on 2015-10-24
11:26:01
| Re: Commodore Basic's oddnesses
@JamesC
Thanks, seems my interpretation is not too far from the native speakers. Do I see right that you gave us some nice HGttG references as examples?
|
|
Posted By
JamesC
on 2015-10-24
10:15:58
| Re: Commodore Basic's oddnesses
@Litwr and @Gerliczer: I use oddity for a physical object, and oddness to describe an unusual personal trait.
Examples:
- the birdcage on Zaphod's shoulder was an oddity Arthur had never encountered.
- Fenchurch's only oddness was that her feet did not touch the ground.
Applying these usages to the thread topic:
- an oddity is something unusual but within CBM specifications (your machine and my machine do the same, though an Apple II may behave differently)
- an oddness is when your own machine's behaviour changes (my machine does not do the same)
@Litwr, if the loop is structured properly, there is no need for a GOTO to exit it. Your example equates to this:
1000 DO WHILE DISH IS DIRTY
1001 : GOTO 1000
1002 LOOP
In your example, the dish is never washed. I would write it this way:
1000 DO
1001 : PUT DISH IN HOT SOAPY WATER
1002 : SCRUB DISH
1003 : EXAMINE DISH
1004 LOOP UNTIL DISH IS CLEAN
1005 DRY DISH WITH TOWEL
1006 PUT DISH IN CUPBOARD
Or if you want an infinite loop, omit the DO:LOOP completely.
1000 GOTO 1000
@SVS, I see what you did there. :P
|
|
Posted By
SVS
on 2015-10-24
06:16:46
 | Re: Commodore Basic's oddnesses
[OT] Oddity is part of the title of one of my favorite songs (Space Oddity) 
|
|
Posted By
gerliczer
on 2015-10-24
04:57:59
| Re: Commodore Basic's oddnesses
Oddness is the fact of something being odd. Oddity is a thing being odd. They are not exactly freely exchangeable. But that's only my understanding of this. Maybe someone with better English will clarify it.
|
|
Posted By
Litwr
on 2015-10-24
04:09:33
| Re: Commodore Basic's oddnesses
@JamesC In any other (?) Basic this sequence of statements means just an infinite loop. I can even add that this is true even for C++ mentioned by gerliczer.
l0:while(1)goto l0;
The only purpose of GOTO in the structural programming is to exit from the nested loops...
I am always trying to improve my English. I see no difference in the words "oddness" and "oddity". Is it right? Thanks in advance.
|
|
Posted By
gerliczer
on 2015-10-23
01:42:46
| Re: Commodore Basic's oddnesses
@Litwr
What natural logic? I'm doing programming work in C++. My logic dictates that a FOR should have any kind of index. So what? The fact that your needs would be better met with integer cycle index doesn't mean that the logic the implementers were adhering to is wrong. They probably decided to use only float because it covers all numerical values in Commodore BASIC. It must have been also an implementation decision that FOR doesn't check for invalid repeat conditions.
|
|
Posted By
JamesC
on 2015-10-22
15:27:39
| Re: Commodore Basic's oddnesses
@Litwr, you get an Out of Memory error because the loop never closes. Therefore the DO's keep building up on the stack.
It's not an oddity with Commodore Basic, as GOSUBs without RETURNs could do the same thing.
|
|
Posted By
Litwr
on 2015-10-22
15:05:22
| Re: Commodore Basic's oddnesses
It is not about the violation of some standards. It is about violation of the natural logic. It is very obvious to have integers in FOR. And, for example, "FOR i=1 to 2 step 1" naturally means 2 times so as "FOR i=2 to 1 step 1" means 0 times.
BTW I can name 4th odd thing in Commodore Basic. It doesn't allow GOTO from loops! See an example
10 do while 1
20 goto 10
30 loop
This code causes "out of memory error". So I had to use GOTO and IF for loops in NOTEPAD+4.
|
|
Posted By
gerliczer
on 2015-10-22
05:07:43
| Re: Commodore Basic's oddnesses
I wouldn't call these oddities. They are implementation decisions. Back in those days there were no BASIC standards, AFAIK.
|
|
Posted By
SVS
on 2015-10-22
03:17:37
| Re: Commodore Basic's oddnesses
Yes the Austrospeed allows integer variables in FOR...NEXT gaining more exec speed.
Another oddness in cycles is that at least one cycle is always executed. This is bad.
For example the cycle:
FOR A=2 TO 1
PRINT "WOW"
NEXT
is not skipped and will print "WOW". I suppose this happens because the control is made by NEXT statement.
|
|
Posted By
MMS
on 2015-10-20
18:27:44
| Re: Commodore Basic's oddnesses
yeah, I made a small test and the predefinition did not make any change, as I could see. When I added the 0.5 increment value, it continued without any hichup, so it means that the varaible was real, not integer initially.
I think Isaw some years ago the hint to use integers for FOR (Austrospeed Compiler topic), but at that time I did not notice any difference too.
|
|
Posted By
Litwr
on 2015-10-20
12:16:02
| Re: Commodore Basic's oddnesses
[MMS] Alone assignment differs from an assignment in FOR: FOR assignment should provide a link to the variable which will be changed by STEP value later. BTW It is curious that Pascal forbids reals in FOR, it allows integers, characters, boolean values, ... So Commodore Basic is antipascalish.
|
|
Posted By
RKSoft
on 2015-10-20
11:38:01
 | Re: Commodore Basic's oddnesses
Strange, it doesn't work under BASIC 2.0, too.
|
|
Posted By
MMS
on 2015-10-19
18:19:46
| Re: Commodore Basic's oddnesses
It does not make a difference if you predefine the type of the index variable?
Like LET A%=1 initially, then let it go?
|
|
Posted By
JamesC
on 2015-10-18
15:31:00
| Re: Commodore Basic's oddnesses
@RKSoft, they're talking about the index variable.
FOR A% = 1 TO 50 : PRINT A% : NEXT <-- gives a Syntax Error because the index variable (A%) cannot be an integer under Commodore Basic.
|
|
Posted By
RKSoft
on 2015-10-18
13:02:14
| Re: Commodore Basic's oddnesses
ehm, i tested it with YAPE 1.0.7 and it works with integer in for...next
10 A%=10:B%=2:C%=1.5
20 FORI=B%TOA%STEPC%
30 PRINTI
40 NEXTI
It works. When you set C% to 0.5 it round down to 0 and run endless.
What did you mean exactly?
|
|
Posted By
Litwr
on 2015-10-18
10:12:37
| Re: Commodore Basic's oddnesses
My point was that all other known to me Basics allow integers in FOR and don't require ':' before ELSE. However I agree with your point too.
|
|
Posted By
Csabo
on 2015-10-18
08:13:25
| Re: Commodore Basic's oddnesses
Yeah, those are perhaps odd at first blush. But if you think about it, they probably had very good reasons to do it that way.
The problem with integers in for loops would be the STEP clause. FOR A%=1 TO 10 STEP 0.5 ... Now what?
The IF-ELSE thing is even more clear cut: our BASIC has no concept of "program blocks" (like begin/end in Pascal or curly braces in C/Java). Therefore the syntax is IF (condition) THEN statement1 : statement2 : statementN : ELSE statement(s). The point is, there can be multiple statements before an ELSE, and those do have to be separated by colons.
So yeah, maybe a little odd, but it does make sense, I think. It's not like our Respected Elders(TM) were infallible, but they did make some pretty amazing, well thought-out stuff long before out time
|
|
Posted By
Litwr
on 2015-10-18
08:04:30
| Commodore Basic's oddnesses
I know two of them.
1. It doesn't allow integers in the FOR loop!
2. Its IF-ELSE statement requires ':' before ELSE.
Who know more?
|
|
