CAOTD (*): JavaScript is the new Assembly
-
Okay, BASIC I'll go for, but don't impugn Assembly. It takes far more knowledge of hardware, and programming skill, to build a useful program using Assembly than any of the modern languages. And yes, sometimes it has to be done...
Will Rogers never met me.
Does this assembly stuff look like this? :)
; =========================================================================================
; Parameters:
; RE.0 X coordinate of the sprite
; RE.1 Y coordinate of the sprite
; RF Pointer to sprite
; RD Size of the sprite in bytes
;
; Internal:
; RC Pointer to video memory
; =========================================================================================DrawSprite: DEC R2
LDI hi(DisplayBuffer) ; calculate the offset in the video buffer
PHI RC ; DisplayBuffer + Y * 8 + X / 8
GHI RE ; result goes to RCIF Resolution == 20H ANI 1FH ; between 0 - 31 ENDIF IF Resolution == 40H ANI 3FH ; or 0 - 63 ENDIF IF Resolution == 80H ANI 7FH ; or 0 - 127 ENDIF SHL SHL SHL PLO RC BNF DSP\_SkipIncrement GHI RC ADI 01H PHI RCDSP_SkipIncrement: GLO RC
STR R2
GLO RE
ANI 3FH
SHR
SHR
SHR
ADD
PLO RC
GLO RE ; calculate the number of required shifts
ANI 07H ; result to RE.1, replacing the Y coordinate
PHI RE ; RE.0 will be used later to count the shiftsDSP_ByteLoop: GLO RD ; exit if all bytes of the sprite have been drawn
BZ DSP_ExitIF Resolution == 20H ; or if we are about to draw outside the video buffer LDI hi(DisplayBuffer) ; only one page at 64 x 32 ENDIF IF Resolution == 40H LDI hi(DisplayBuffer) + 1 ; two pages at 64 x 64 ENDIF IF Resolution == 80H LDI hi(DisplayBuffer) + 3 ; four pages at 64 x 128 ENDIF STR R2 GHI RC SD BNF DSP\_Exit LDN RF ; load the next byte of the sprite into RB.0 PLO RB LDI 00H ; set RB.1 to OOH PHI RB DEC RD ; decrement the sprite's byte counter INC RF ; increment the pointer to the sprite's bytes GHI RE ; prepare the shift counter PLO REDSP_ShiftLoop: GLO RE ; exit the loop if all shifts have been performed
BZ DSP_ShiftExit
DEC RE ; decrement the shift counter
GLO RB ; shift the values in RB
SHR
PLO RB
GHI RB
RSHR
PHI RB
BR DSP_ShiftLoop
DSP_ShiftExit: SEX RC ; store the shifted bytes in the video buffer
GLO RB
XOR
STR RC
INC RC
GHI RB
XOR
STR RC
SEX R2
GLO RC ; advance the video buffer pointer to the next line
ADI 07H
PLO RC
GHI RC
ADCI 00H
PHI RC
BR DSP_ByteLoop
DSP_Ex -
Does this assembly stuff look like this? :)
; =========================================================================================
; Parameters:
; RE.0 X coordinate of the sprite
; RE.1 Y coordinate of the sprite
; RF Pointer to sprite
; RD Size of the sprite in bytes
;
; Internal:
; RC Pointer to video memory
; =========================================================================================DrawSprite: DEC R2
LDI hi(DisplayBuffer) ; calculate the offset in the video buffer
PHI RC ; DisplayBuffer + Y * 8 + X / 8
GHI RE ; result goes to RCIF Resolution == 20H ANI 1FH ; between 0 - 31 ENDIF IF Resolution == 40H ANI 3FH ; or 0 - 63 ENDIF IF Resolution == 80H ANI 7FH ; or 0 - 127 ENDIF SHL SHL SHL PLO RC BNF DSP\_SkipIncrement GHI RC ADI 01H PHI RCDSP_SkipIncrement: GLO RC
STR R2
GLO RE
ANI 3FH
SHR
SHR
SHR
ADD
PLO RC
GLO RE ; calculate the number of required shifts
ANI 07H ; result to RE.1, replacing the Y coordinate
PHI RE ; RE.0 will be used later to count the shiftsDSP_ByteLoop: GLO RD ; exit if all bytes of the sprite have been drawn
BZ DSP_ExitIF Resolution == 20H ; or if we are about to draw outside the video buffer LDI hi(DisplayBuffer) ; only one page at 64 x 32 ENDIF IF Resolution == 40H LDI hi(DisplayBuffer) + 1 ; two pages at 64 x 64 ENDIF IF Resolution == 80H LDI hi(DisplayBuffer) + 3 ; four pages at 64 x 128 ENDIF STR R2 GHI RC SD BNF DSP\_Exit LDN RF ; load the next byte of the sprite into RB.0 PLO RB LDI 00H ; set RB.1 to OOH PHI RB DEC RD ; decrement the sprite's byte counter INC RF ; increment the pointer to the sprite's bytes GHI RE ; prepare the shift counter PLO REDSP_ShiftLoop: GLO RE ; exit the loop if all shifts have been performed
BZ DSP_ShiftExit
DEC RE ; decrement the shift counter
GLO RB ; shift the values in RB
SHR
PLO RB
GHI RB
RSHR
PHI RB
BR DSP_ShiftLoop
DSP_ShiftExit: SEX RC ; store the shifted bytes in the video buffer
GLO RB
XOR
STR RC
INC RC
GHI RB
XOR
STR RC
SEX R2
GLO RC ; advance the video buffer pointer to the next line
ADI 07H
PLO RC
GHI RC
ADCI 00H
PHI RC
BR DSP_ByteLoop
DSP_ExYup.. That's the stuff. :-D
Will Rogers never met me.
-
Yup.. That's the stuff. :-D
Will Rogers never met me.
Ahh, good morning (at leat it is early morning here). I got this drivel from here[^]. While I don't enjoy JavaScript very much, I still have some assembly which I occasionally work on. The code I have posted is used to draw a bitmap patten at any screen coordinates. I use it for text output, but also can be used to draw sprites in a game. That's why ther also collison detection. :)
Sent from my BatComputer via HAL 9000 and M5
-
In the UK they are planning plain packaging on cigarette packets - just think of all the extra space for sketching designs such as these.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Amitosh S.M. wrote:
If I had a time machine, I would have gone to past and burnt the blueprints!!!
I would go back even further and burned the original implementation of HTML! Marc
Hear hear! (I could go into a similar rant about failing to learn from existing technologies to my SQL one they other day. In this case forerunners such as Doug Englebart (The Mother of all Demos), Ted Nelson (who coined the phrase Hypertext) and Apple's HyperCard. They really should stop these scientists hacking.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
In the UK they are planning plain packaging on cigarette packets - just think of all the extra space for sketching designs such as these.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
It would be better to say that JavaScript is the new C64 BASIC. It's just as fast, efficient and fun to debug as any old interpreter and allows any {place insulting word of choice here] who was too dumb to understand object orientation or get used to data types to freely create programing horrors. (*) Cool-Aid of the day. Have a big cup. :)
Sent from my BatComputer via HAL 9000 and M5
CDP1802 wrote:
allows any {place insulting word of choice here]
I believe that code block is not properly closed. I don't think you would want to debug that kind of error in a Javascript file...
This isn't a signature
-
Hear hear! (I could go into a similar rant about failing to learn from existing technologies to my SQL one they other day. In this case forerunners such as Doug Englebart (The Mother of all Demos), Ted Nelson (who coined the phrase Hypertext) and Apple's HyperCard. They really should stop these scientists hacking.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Rob Grainger wrote:
and Apple's HyperCard.
I actually wish HyperCard was still around - I guess we have PowerPoint nowadays, but it's really not the same thing. One day I'll get back to working on http://app.intertexti.com/[^], my resurrection attempt (sort of.) ;) Marc
-
CPallini wrote:
Blueprints?
Something used in Medieval times (My sophomore year of college) to make inexpensive copies of plans. Huge sheets of paper were used to create drawings of a design. (Written by hand, in pencil. Computers did exist, but were rather mythical. The head office was rumored to have one!) Another sheet the same size was immersed in chemicals was placed up to the plan, a special light was shined through both. The pencil marks blocked the light, the rest of the paper reacted to the light and turned blue, while the blocked portions remained white. In ancient times, this was the way structures were built. To this day, any kind of plan in any kind of medium is still called a blueprint by a fair segment of the population. (Mostly by people who have actually seen a blueprint or were infected by the people who still call it that.)
-
Amitosh S.M. wrote:
If I had a time machine, I would have gone to past and burnt the blueprints!!!
I would go back even further and burned the original implementation of HTML! Marc
-
CPallini wrote:
Blueprints?
Something used in Medieval times (My sophomore year of college) to make inexpensive copies of plans. Huge sheets of paper were used to create drawings of a design. (Written by hand, in pencil. Computers did exist, but were rather mythical. The head office was rumored to have one!) Another sheet the same size was immersed in chemicals was placed up to the plan, a special light was shined through both. The pencil marks blocked the light, the rest of the paper reacted to the light and turned blue, while the blocked portions remained white. In ancient times, this was the way structures were built. To this day, any kind of plan in any kind of medium is still called a blueprint by a fair segment of the population. (Mostly by people who have actually seen a blueprint or were infected by the people who still call it that.)
-
Marc Clifton wrote:
I would go back even further
Hate to tell you this, but blueprints predate HTML about a hundred years. You would have to go back even sooner.
KP Lee wrote:
but blueprints predate HTML about a hundred years.
Harhar. Well, then we might as well go back to the discovery of the wheel. Or better yet, fire. ;) Marc
-
CDP1802 wrote:
allows any {place insulting word of choice here]
I believe that code block is not properly closed. I don't think you would want to debug that kind of error in a Javascript file...
This isn't a signature
-
I know that. However it would imply there were a plan behind JavaScript. :-D
Veni, vidi, vici.
-
KP Lee wrote:
but blueprints predate HTML about a hundred years.
Harhar. Well, then we might as well go back to the discovery of the wheel. Or better yet, fire. ;) Marc
Sorry, misstated that, I intended that when you were moving back in time you would have to hit the breaks sooner to hit just before HTML. IE less distance back in time, not more. I may have also totally misread what you said. By the way, since you want something better than HTML at a time when HTML was a trailblazing concept, how would you go about convincing the designer "your" idea is better?
-
It would be better to say that JavaScript is the new C64 BASIC. It's just as fast, efficient and fun to debug as any old interpreter and allows any {place insulting word of choice here] who was too dumb to understand object orientation or get used to data types to freely create programing horrors. (*) Cool-Aid of the day. Have a big cup. :)
Sent from my BatComputer via HAL 9000 and M5
I think that's why I like JS so much - it reminds me of the C64. However, I wouldn't use it for large applications, but scripts of a few hundred or thousand lines or so are fun to code in JS. I like OOP too, though I often think it's an overkill on simple scripts. I suppose as a hobbyist I don't have to deal with a hundred thousand lines plus of code, which would probably change my perspective.
-
Sorry, misstated that, I intended that when you were moving back in time you would have to hit the breaks sooner to hit just before HTML. IE less distance back in time, not more. I may have also totally misread what you said. By the way, since you want something better than HTML at a time when HTML was a trailblazing concept, how would you go about convincing the designer "your" idea is better?
KP Lee wrote:
how would you go about convincing the designer "your" idea is better?
By bringing a laptop back with me and showing him the nightmare that web development has become. ;) Marc
-
KP Lee wrote:
how would you go about convincing the designer "your" idea is better?
By bringing a laptop back with me and showing him the nightmare that web development has become. ;) Marc
Marc Clifton wrote:
...showing him the nightmare...
HTML is a simple markup language, originally designed to provide a reporting process over the web, it isn't complex enough to make the web a nightmare. You can't really lay the web environment we have now at its feet.
